[vim/vim] WinEnter fires for new buffer but setlocal cursorline has no effect (Issue #19993)
Jim Hill
jthill created an issue (vim/vim#19993)Steps to reproduce
- This vimrc or however you want to do it
augroup .vimrc
au!
au VimEnter,WinEnter * setlocal cursorline
au WinLeave * setlocal nocursorline
augroup END
:helpor anything that splits a new window and buffer. cursorline won't be on in the new window.
Expected behaviour
cursorline is documented and behaves as window-local, and if you split to an existing buffer, for instance if you do :5sp to get a new window on the current buffer, it will be lit in the new window
WinEnter does fire as advertised for the new buffer, if you put echo "hi" in there you see it, but cursorline there isn't working.
There's a workaround, ish, but having to use BufWinEnter just for that one case feels ugly enough to fix, nothing about the curosrline docs suggests it's got anything to do with which buffer's there.
Version of Vim
9.2, patches 1-357, compiled by ArchLinux
Environment
Arch Linux
xterm-256color
bash
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)nothing about the curosrline docs suggests it's got anything to do with which buffer's there.
:h local-options
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jim Hill
jthill left a comment (vim/vim#19993)nothing about the curosrline docs suggests it's got anything to do with which buffer's there.
:h local-options
Did I miss something?
When I do what you suggest I see :h local-options emphasizing that window-local options aren't tied to any buffer or type.
And :h cursorline says it's a window-local option.
Local-options says the global settings for window-local options are applied to new windows; if they're applied after WinEnter runs in a new window, that's the bug,
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)emphasizing that window-local options aren't tied to any buffer or type.
Where does it emphasize that?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)emphasizing that window-local options aren't tied to any buffer or type.
Where does it emphasize that? It says the opposite:
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|.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)I think you should change :setlocal to :set. :setlocal only sets the option of one buffer in that window, and as mentioned in :h WinEnter:
Note: For split and tabpage commands the
WinEnter event is triggered after the split
or tab command but before the file is loaded.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jim Hill
jthill left a comment (vim/vim#19993)In the situations your quoted paragraph describes, au WinEnter * setlocal cursorline works perfectly.
That's not the situation in the bug report, though, and in the situation in the bug report, it doesn't work at all.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)Look below:
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jim Hill
jthill left a comment (vim/vim#19993)Yes, it says that. I'm not editing "another buffer" in that window, I'm not editing an old buffer in that window, I'm in the situation described in the problem report. Could you please stop dragging in documentation describing how vim behaves in irrelevant situations?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)emphasizing that window-local options aren't tied to any particular buffer.
That's the case of :set, not :setlocal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)I'm not editing "another buffer" in that window
But you are using a WinEnter autocommand. To WinEnter autocommands, the buffer that hasn't been loaded yet is "another buffer".
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jim Hill
jthill left a comment (vim/vim#19993)I wasn't aware the doc was written only well enough that it's possible, if you already know how the code's written, to find in interpretation that matches how the code's written.
If that's good enough for you, well, that's your call.
I'll continue thinking doc should be written so that humans reading it can learn how it's going to work without having to be surprised and then find out by some other means.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19993)Yes, the docs is still a bit confusing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jim Hill
jthill left a comment (vim/vim#19993)Heh. Thanks for working on the docs, I just finished cloning and was trying to cook up a reword myself.
I still think setlocal for window-local options should work reliably in WinEnter and WinNew, it feels wrong that you can't prevent inappropriate defaults being applied when the window really is new, But for now I've just overridden the default globally.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.