I don't understand the purpose and behavior of options "local to a window"

Question

I don't understand the purpose of options that are "local to a window", such as for example colorcolumn and how they behave.

This is a sequence to demonstrate what I mean:

I start gvim. An empty, unnamed buffer appears.

I open an inexsting file without a file type associated with it:

:e c:\temp\abc.foo

write some text and set colorcolumn to 1

:set cc=1

and write the buffer to disk

:w

I split the window

:split

and edit another inexsting file

:e c:\temp\def.foo

When writing some text, I see that the color column is set to 1. Which is what I expected, since vim copies the value from the currently active buffer.

I set the color column to 2

:set cc=2

and write this buffer

:w

and start to edit yet another new file

:e c:\temp\ghi.foo

Again, the color column option value is copied from the currently active windows and set to 2. This is still what I expected.

I switch the buffer to the buffer below <Ctrl-W>+j so that I am in c:\temp\abc.foo, the color column option value of which is 1.

I start editing def.foo in that window:

:bu def.foo

Now, the color column option value is 2, which I have previously set for that buffer, but not for that window. Here, I'd have expected the value to be 1 because it is an option "local to a window".

Can someone explain the rational of this behavior?

Answer 1

local to window doesn't mean every buffer you loaded in the same window has the same local to window options.

create new window

From :h local-options :

When splitting a window, the local options are copied to the new window. Thus right after the split the contents of the two windows look the same.

load new buffer

When you load new buffer into window, global window options are used, the current local to window options are totally ignored, i believe this part works exactly the same as local to buffer. When you call set cc=.., both local and global values are changed, after you load new buffer, colorcolumn is set from the global one.

load existing buffer

From :h local-options :

When editing a buffer that has been edited before, the options from the window that was last closed are used again. If this buffer has been edited in this window, the values from back then are used. Otherwise the values from the last closed window where the buffer was edited last are used.

IMHO, the doc is not precise, it should be the options from the window that the buffer was last unloaded (from window, not from memory) are used again, it doesn't matter if the window is closed or not, so both :q and :e another_buffer counts. It works like the buffer is never unloaded, everything is remembered, that's what most people desired. This explains why the last colorcolumn is 2.

If the last unload window doesn't exists, the buffer is currently loaded in other window or windows (might be multiple), i believe local options are copied from the last window that load the buffer.

Experiment

To help you understand the behavior of loading existing buffer, do this step by step :

vim /tmp/abc

Copy following commands and execute them with :@+

:setlocal colorcolumn=10
:wincmd v
:wincmd l
:setlocal colorcolumn=20

Left window has colorcolumn set to 10, right window has colorcolumn set to 20, check it with setlocal colorcolumn? (If you can see the column, check with your eye). Continue:

:h
:b abc

:h is used to avoid split with the same buffer. check setlocal colorcolumn?, it should be 20, which is the same as bottom right window, as bottom right window is the last window that load the buffer when no last unload window exists. Continue:

1wincmd w
edit /tmp/balabala
setlocal colorcolumn=30

These commands goto left window, edit a new buffer (cause unload of original buffer), and set local colorcolumn to 30, check it with setlocal colorcolumn?. Continue:

:b abc

Check setlocal colorcolumn?, it should be 10, the same as before it's unloaded, it's set from the last unload window. Continue

:2wincmd q
:h
:b abc

Check setlocal colorcolumn?, it should be 20, it's set from the last unload window (caused by q).