You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've recently implemented support in Neovim for color palette notifications. Having implemented, I have some feedback and suggestions for ways it could be modified to help our use case.
We are using these notifications to detect when the background color of the terminal has changed. In Neovim's case, we don't care about the OS appearance (at least not right now), all we care about is the terminal's background color. When we receive one of these notifications we send an OSC 11 query to determine the terminal's background color and update the 'background' option appropriately.
However, we end up receiving a lot of these notifications because Neovim changes or resets the cursor color frequently (the user can set the 'guicursor' option which can modify the color and shape of the cursor based on the current mode). Every time this happens, we get a color palette update notification, we query the terminal's background color, and we update 'background'. This causes a lot of unnecessary "noise", both in unneeded terminal I/O but also in user-facing OptionSet events everytime 'background' is set (even if the option's value doesn't change).
Suggestions
Since all we (Neovim) care about is the terminal's background color, it would be great to be able to have more granularity about what changed in the DSR. I can think of two ways to do this:
When we enable mode 2031, allow the application to specify which events it's interested in. In Neovim's case, we would "register" only for terminal background color changes. Other applications may choose to be notified for foreground color changes, or OS appearance changes. The drawback here is that I don't think this is possible with DECSET, since it doesn't take parameters.
Include more parameters in the DSR response to indicate what actually has changed. The parameters would include e.g. 10 for a foreground color change, 11 for a background color change, 12 for a cursor color change, and perhaps 4 for a palette color change (to match the OSC sequences). So for instance, if the OS appearance changed to black and background color changed, the terminal would send CSI ? 997 ; 1 ; 11 n. With this approach, Neovim would know to only query for the background color when the terminal's background color changed.
Please let me know your thoughts. Thanks for spearheading this feature, a lot of our users are very excited about it.
The text was updated successfully, but these errors were encountered:
Hi!
I've recently implemented support in Neovim for color palette notifications. Having implemented, I have some feedback and suggestions for ways it could be modified to help our use case.
We are using these notifications to detect when the background color of the terminal has changed. In Neovim's case, we don't care about the OS appearance (at least not right now), all we care about is the terminal's background color. When we receive one of these notifications we send an OSC 11 query to determine the terminal's background color and update the
'background'
option appropriately.However, we end up receiving a lot of these notifications because Neovim changes or resets the cursor color frequently (the user can set the
'guicursor'
option which can modify the color and shape of the cursor based on the current mode). Every time this happens, we get a color palette update notification, we query the terminal's background color, and we update'background'
. This causes a lot of unnecessary "noise", both in unneeded terminal I/O but also in user-facingOptionSet
events everytime'background'
is set (even if the option's value doesn't change).Suggestions
Since all we (Neovim) care about is the terminal's background color, it would be great to be able to have more granularity about what changed in the DSR. I can think of two ways to do this:
When we enable mode 2031, allow the application to specify which events it's interested in. In Neovim's case, we would "register" only for terminal background color changes. Other applications may choose to be notified for foreground color changes, or OS appearance changes. The drawback here is that I don't think this is possible with DECSET, since it doesn't take parameters.
Include more parameters in the DSR response to indicate what actually has changed. The parameters would include e.g.
10
for a foreground color change,11
for a background color change,12
for a cursor color change, and perhaps4
for a palette color change (to match the OSC sequences). So for instance, if the OS appearance changed to black and background color changed, the terminal would sendCSI ? 997 ; 1 ; 11 n
. With this approach, Neovim would know to only query for the background color when the terminal's background color changed.Please let me know your thoughts. Thanks for spearheading this feature, a lot of our users are very excited about it.
The text was updated successfully, but these errors were encountered: