Nice! However, couldn't this be implemented as some sort of flag to the :hi command, something like hi local link Normal HighlightGroup? Then, it would be fully general, no?

Yes, but that would be a lot more complicated. For ui highlighting there is the HLF_ caching that assumes ui highlights are global, and for syntax, well there is :ownsyntax as a workaround. It might be a worthwhile project, but I don't think it should block this rather simple PR.

The only addition I would consider is support two values for active/inactive window as I guess that is a common usecase. Or maybe people should just use WinEnter/WinLeave.

Oh, for sure. It was just a thought (main concern is that you are introducing a setting which might become obsolete by b some mechanism like above). Maybe the setting could be extensible so it is similar to the way guicursor works (taking a list of items and their attributes).

Maybe the setting could be extensible so it is similar to the way guicursor works (taking a list of items and their attributes).

That's a good suggestion, then we can make it clear a few specific groups are overridable, unlike hi local link which would seem to support everything.

I'm unable to get buffer-local behavior for window option as described in local-options

It's possible to set a local window option specifically for a type of buffer.
When you edit another buffer in the same window, you don't want to keep
using these local window options.  Therefore Vim keeps a global value of the
local window options, which is used when editing another buffer.  Each window
has its own copy of these values.  Thus these are local to the window, but
global to all buffers in the window.  With this you can do: >
	:e one
	:set list
	:e two
Now the 'list' option will also be set in "two", since with the ":set list"
command you have also set the global value. >
	:set nolist
	:e one
	:setlocal list
	:e two
Now the 'list' option is not set, because ":set nolist" resets the global
value, ":setlocal list" only changes the local value and ":e two" gets the
global value.  Note that if you do this next: >
	:e one
You will get back the 'list' value as it was the last time you edited "one".
The options local to a window are remembered for each buffer.  This also
happens when the buffer is not loaded, but they are lost when the buffer is
wiped out |:bwipe|.

Is there a checklist somewhere for all the places a new window option, there are quite a few....

Indeed. For example, what would hi local link Statusline Group do? So I agree, that is not a good idea.

I'm unable to get buffer-local behavior for window option as described in local-options

Why not make it buffer-local? See 7bc37ff for how 'scrollback' was converted from "global" to buffer-local.

Is there a checklist somewhere for all the places a new window option, there are quite a few...

Do you mean in the C code? Top of option.c is mostly sufficient.

If it's any help, see #6337 (comment)
(tl;dr global-local is different than buffer-local; buffer-local actually has "global default" capability).

Thanks for the pointers. The top of option.c is not complete, doesn't mention check_winopt and clear_winopt. An option with sideeffects also in get_winopts and win_init. But briopt is for some reason in win_copy_options; this only gets called by win_init but not by buffer_enter so it does not work. I will update the head of option.c and maybe factor out didset_window_options.

This is now set winhl=normal:TheGroup,morestuff:AnotherGroup, but for the moment only normal, maybe should add inactive for background of inactive window.

Added inactive variant, so now fixes #5302 .

marking RFC.

would it be much trouble to make matchadd()/matchaddpos() support changing the bgcolor?
Should we just accept that "Normal bg is special"?
#5302 (comment)

No. Background is not special, it is just the intended usecase. You can override fg color and attributes. It would seem like a big stretch to let matchadd() add highlights where there is no text, both after end of line, and EOB. matchadd() also can't be buffer-specific.

Right, matchadd() is the wrong mechanism because one cannot "match" non-text. I guess what I'm looking for is a way to decorate cells by XY coordinates. Anyways, that can wait until later.

and bufhl can't be window-global, though it could make sense to allow matchadd or bufhl to highlight the gap between end of a logical line and the physical line.

But the main point is that this will be needed for (hopefully future) builtin functionality (floating windows), and such should have a builtin mechanism.

segfault in win_enter_ext:

https://gist.github.com/2ec9f8d3a442560ca38515dd0927b1aa

Steps:

nvim -u NONE
:tabnew
:tabclose

Thanks, please try latest commit.

No, it happens even if NonText doesn't have bg, so it is a bug...

should work correctly with non-text highlights now.

@justinmk Should we merge this? There might be more bad interactions, but the best way to find that out is let more people try it. Test errors look quite unrelated.

I found another case where it is not applied: the extends from 'listchars':

lots of ad-hoc logic... For some reason the terminal has its own beyond-end-of-line loop, instead of reusing the existing one. Someone disabled colorcolumn in terminal instead of bothering fixing it proberly, but you can the same breakage using cursorcolumn...

should work with precedes and extends now.

Hey, @blueyed, I was a happy user of vim-diminactive before, and now I'm an even happier user of the snipped you supplied above. Have you noticed, though, that it won't change the background if there isn't a file open, that is to say, if you open vim without supplying a filename? Incidentally, if you do that, open an empty split, then move between them, the original split all of a sudden starts changing background, but the new one doesn't.

@rafaeln
Thanks!
I am using a modified version locally already, and plan to integrate it into vim-diminactive, so that it uses Neovim's method if it is available instead of the colorcolumn hack. Not sure if I'll finish it this soonish though.
I've updated the snippet above (#6597 (comment)), which should also fix your issue if I understand it correctly.

Hi, @blueyed, is the snippet still working for you? It was maybe after I upgraded neovim today that it stopped working for me. Specifically, it still works between vim splits, but stopped working between a vim pane and other tmux panes. I tried to understand better what was going on and so far I found that Focus{Gained,Lost} events are still being detected.

Now the snippet got even weirder...

@rafaeln
It worked until recently for me.
This broke it: #7082 (comment)