On May 12, 1:55 pm, Andy Wokula <[email protected]> wrote: > Ben Fritz schrieb: > > > I posted this originally on vim_use but only got one response, from > > someone who thinks it's a bug. The original thread is here: > > >http://groups.google.com/group/vim_use/browse_thread/thread/d93a0878b... > > > Basically, I have two tabs open, each with a single buffer loaded, and > > a BufRead autocmd that will fire when the file in one of the tabs is > > (re)loaded. This BufRead autocmd sets the "wrap" option locally. When > > the autocmd fires, the buffer in the currently active tab gets the > > option, regardless of whether this is the buffer being reloaded.
[snip] > The 'wrap' option is local to the window. (Obviously) Vim does not > switch to the buffer's window when reloading a file -> the option can be > set in the wrong window. I also had some battles with window local options, and 'wrap' in particular, in the past. The way window local options are both 'window local' and 'buffer local' can be mighty confusing. For instance, do vim -u NONE -N file1.txt file2.txt :bn :setl nowrap Now :setl wrap? returns 'wrap' for file1.txt and 'nowrap' for file2.txt (in the same window). However, doing :b1 :for i in [1,2] | echo bufname(i) . ": &l:wrap = " . getbufvar(i, "&l:wrap") | endfor :b2 :for i in [1,2] | echo bufname(i) . ": &l:wrap = " . getbufvar(i, "&l:wrap") | endfor prints file1.txt: &l:wrap = 0 file2.txt: &l:wrap = 0 file1.txt: &l:wrap = 1 file2.txt: &l:wrap = 1 Thus, getbufvar() actually only returns the window local state of an option which is actually dependent on both window local and buffer local state. I'm sure there's a good(?) explanation for this, but I haven't found it. Eventually I was convinced that this is the way that Vim works, and just gave up on trying to set 'wrap' automatically. I would argue that some window local options, such as 'wrap' and 'diff', should be local to buffer instead, but I'm sure there are plenty of valid arguments against this as well. Regards, Henrik. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
