[vim/vim] Setting local value of global-local window option sets local value for other buffers in window (Issue #12596)
Dani Dickstein
Steps to reproduce
setlocal scrolloff=2 setglobal scrolloff=3 setl modified " Force fresh buffer with enew hide enew echo &l:scrolloff &g:scrolloff
The script above prints "2 3". I don't understand why the local value of the new buffer is set to 2. If this is expected, is there documentation that explains this behavior?
Expected behaviour
The script should print -1 3
Version of Vim
9.0.1664
Environment
Linux
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
'scrolloff' is global-local to a window. What happens when you edit a new buffer in the same window, is that the local value of the existing window option is kept.
It's also explained in much detail at :h local-options
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
Oh, I fundamentally misunderstood "Global or local to window" options. I had thought that these were scoped like window-local options, meaning that global scope was local to a window and local scope was local to a buffer in a window, but with the global-local mechanics of a default global value. Now I see that actually global is meant to be proper global scope, and local is meant to apply to the whole window. So only window-local options are per-(buffer,window). Please confirm my new understanding is correct; if it is, feel free to close this issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
Perhaps tellingly, scrolloff and sidescrolloff are missing from https://github.com/vim/vim/blob/590aae35575cbd74d80c41d87fc647f2812aad70/src/structs.h#L177C1-L326C12
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
those are again global-local to window, while the options in winopt_T seem to be local to window. So 'sidescrolloff' and 'scrolloff' are part of the wind_T type:
https://github.com/vim/vim/blob/bf5f189e449d6517239b79804d7a422a46946838/src/structs.h#L3980-L3981
See also:
https://github.com/vim/vim/blob/bf5f189e449d6517239b79804d7a422a46946838/src/structs.h#L3956-L3964
Hm, except that this does not seem to be entirely true anymore, there are several global-local window options now also in winopt_T
- 'listchars', which now is also global-local to window which was changed back in eed9d46
- 'fillchars' which was also changed to global-local to window in 96ba25a
- 'virtualedit' changed in 53ba05b and then later in 51ad850
- 'showbreak' changed in ee85702
- 'statusline'
Perhaps 'sidescrolloff' and 'scrolloff' should indeed also be there. Not sure, seems like techical debt 🤷♂️
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
are we fine to close?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
I don't think so. I think that either there needs to be a change in behavior for scrolloff and sidescrolloff to make them behave like the other global-local window options, or they need to be called something different since there are semantics of global-local window options laid out in the manual that these options violate.
And I agree with your second note in your post above - membership in winopt_T does not seem to imply anything about local v. global-local status.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I don't think so. I think that either there needs to be a change in behavior for scrolloff and sidescrolloff to make them behave like the other global-local window options, or they need to be called something different since there are semantics of global-local window options laid out in the manual that these options violate.
Sorry, I don't follow. Did you mention what behaviour was different with those two options in comparison to other global-local window options?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
Yes - sorry if that was unclear.
" 1. Confirm local values are unset (scrolloff is -1 when unset): :setl listchars? :setl scrolloff? " 2. Set the local values. :setl listchars=tab:>> :setl scrolloff=2 " 3. Change the buffer in the window. :setl modified :hide enew " 4. Check local options again :setl listchars? " empty; tracking global option :setl scrolloff? " 2; local value is set
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
A more complete accounting of behavior differences I found is here - neovim/neovim#24156 (comment) (I did that testing in Neovim so it's possible there are some differences).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
okay, I see. Indeed, I didn't know that global-local window options are also local to a buffer.
I have created #12643 to fix this which also includes a small addition to the documentation to make that clear.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
What do you want to do about the other discrepancies mentioned in the issue I linked? Tests demonstrating the differences in the semantics:
This departure from buffer-local behavior affects syntax, filetype, readonly, bufhidden, buftype, modified (also channel in Neovim):
:setg syntax=ocaml :setg commentstring=(*%s*) :new :set syntax? " Empty :set commentstring? " (*%s*)
This departure from window-local behavior affects previewwindow, scroll, winfixheight, winfixwidth:
" Test 1: Global value :setg cursorcolumn :setg winfixwidth :setl modified :hide enew :set cursorcolumn? " Set :set winfixwidth? " Not set
" Test 2: Local value :setl cursorcolumn :setl winfixwidth :setl modified :hide enew :set cursorcolumn? " Not set :set winfixwidth? " Set
For these options I'm not convinced that their difference in behavior is a bug. It kind of makes sense when you think about what these options actually mean -- e.g., setting a syntax for new buffers is probably not something the user actually means to do. But calling them "local to buffer" and "local to window" options like the others is misleading. If we think the current behavior is desired, they deserve their own category of option.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Updated documentation with those options.
If you have any specific documentation recommendation, please show.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
The updated docs look good to me for these special options. I noticed that you also removed the note about global-local window options being per-buffer. Why was that removed?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
because it is already mentioned a few lines above at :h local-options
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
I think the text above describes the behavior of the global value for "local to window" options, but it doesn't say anything about the semantics of "global or local to window" options.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
exactly, because it applies to both types of options: global-local options and local options.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
It isn't obvious that that text applies to global-local options though. In particular, this bit:
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.
as well as the fact that the section is titled "Handling of local options" and all of its examples are "local to buffer" or "local to window" options suggest to the reader that nothing in that section is applicable to global-local options. The reader is unlikely to understand that the bits discussing the behavior of the local values of options are applicable, but the bits discussing the behavior of the global values of options are not.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Does that 9b47438 make it more clear?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
No, because the parts of that section that discuss the semantics of global values of local options do not match the semantics of the global values of global-local options.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I don't follow. Afaik, the difference of |global-local| to regular local options is simply that they special in the sense, that usually only use the global value, but may have single local options. But that does not mean, that those |global-local| options do not themselves have (buffer- and window-) local values.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
Yes, but this section of the manual does not discuss local values - it discusses both the global and the local values of regular local options. So saying that the whole section also applies for global-local options is misleading because there is text in there about how global values work and it does not apply to how global values work for global-local options.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
For me, I understand it differently: It does not say at all, whether or not it applies to regular local-options only or not (meaning global-local). It's a high-level summary, of what happens with local options. And since both global-local and buffer/window-local options can have local options, it applies to both.
In any case, I am open to suggestiosn
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dani Dickstein
The changes you are making in #12643 are good and I don't think we should block on it. Let's maybe unwind the note and just close out this issue with your changes as-is. Separately, I'm happy to work together to draft something in a different forum - e.g., a google doc - that tries to make the language clearer, and we (and others interested in helping) can iterate on it freely until we are happy with the text. How does that sound to you?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
fixed by 4a8eb6e
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #12596 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
nyngwang
nyngwang left a comment (vim/vim#12596)Yes, but this section of the manual does not only discuss local values - it discusses both the global and the local values of regular local options. So saying that the whole section also applies for global-local options is misleading because there is text in there about how global values work and it does not apply to how global values work for global-local options. Moreover, the header "local-options" (to me, at least) makes it sound like it's specifically making a point to not be talking about global-local options.
@ddickstein Could you confirm that my confusion there is related your words here? Thanks for your reading.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.