Skip to content

Conversation

teto
Copy link
Member

@teto teto commented Feb 13, 2018

when doing :hi Cursor guibg=red for instance, the cursor color is not
necessarily refreshed straightaway, only on mode change.
This PR notifies the UIs with the ids of the changed highlights, the UI can then use nvim_get_hl_by_id to retrieve the updated hl if need be (it's straightforward for the UI).
Adresses #6591

To test
bin/nvim -u NONE --cmd "set termguicolors" --cmd "set guicursor=n-v-c:block-Cursor/lCursor,ve:ver35-Cursor,o:hor50-Cursor,i-ci:ver25-Cursor/lCursor,r-cr:hor20-Cursor/lCursor"
then type
:hi Cursor guibg=red

On startup it sends several ids depending on your config, i hope it's not a problem.

Extracted from #6566

@teto teto changed the title ui: notify new highlights [RFC] ui: notify new highlights Feb 13, 2018
@teto teto changed the title [RFC] ui: notify new highlights [RFC] ui: notify changed highlights Feb 13, 2018
@bfredl
Copy link
Member

bfredl commented Feb 13, 2018

Why not just include the bg color in the mode_info_set event? Resending that array when hi Cursor (or other hl used for cursor in some mode) is changed doesn't seem too drastic.

Instead of telling an UI "now it's the time for you to ask about the information you need" we should just say "here is the information you need".

@marvim marvim added the RFC label Feb 13, 2018
when doing `:hi Cursor guibg=red` for instance, the cursor color is not
necessarily refreshed straightaway, only on mode change.
This PR notifies the UIs with the ids of the changed highlights.
neovim#6591
@teto
Copy link
Member Author

teto commented Feb 14, 2018

One broader goal was to give UIs the capability to use nvim highlights for their own themes. They can query with nvim_get_hl_by_id/name but they are not notified of highlight updates yet. The PR helps with that.
I was concerned with the amount of data exchanged (especially on start) that's why I send just the hl ids instead of the full description (but the latter might be ok ?).
On the first iteration, I had UIs subscribe to highlights they were interested in to reduce the amount of hl updates but this was a bit tedious. The PR could be adapted to check if any of the highlight changed is used in guicursor and send mode_info_set if that's the case.

@bfredl
Copy link
Member

bfredl commented Feb 14, 2018

I don't disagree with that usecase. But then I think we should make it opt-in and clients that opt-in will receive the full set of highlight data. In fact I think a second version of the grid protocol should use this abstraction sending a damaged line region at once as a compact array of text cells and hl IDs.

But for immediate purpose of cursor color we should just send the needed information in mode_info_set, client shouldn't need to puzzle together two different events to know whether the cursor style changed or not.

@@ -7685,6 +7689,10 @@ void highlight_changed(void)
}
}
highlight_ga.ga_len = hlcnt;

ui_call_highlight_info_set(changed_highlights);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bfredl would removing the *highlight_info_set and call use mode_info_set if needed (on a cursor hl change) be ok ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the only issue is that we might need some kind of batching. If the user reloads their color scheme it should only be sent once in total. Might follow similar scheme as pending_cursor_update in ui.c: when a highlight group changes set it to true, and in ui_cursor_shape send the mode_info_set if the flag is true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants