-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
[RFC] ui: notify changed highlights #8006
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Why not just include the bg color in the 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". |
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
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 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); |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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.
when doing
:hi Cursor guibg=red
for instance, the cursor color is notnecessarily 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