Reply to message «Re: optwin.vim - setlocal on global options ? ...», sent 00:28:57 31 January 2011, Monday by ZyX:
> I don't understand you.
>
> :wincmd v
> :options
> :wincmd h
> :options
>
> will bring me to the first option window. If you meant option window on
> other tab, then Marc's code is just fine: bufwinnr() is not able to find
> window on other tab.
One addition: if option window is opened on some tab, «new option-window» in
other tab will create new window associated with existing buffer, so it should
probably be fixed.
Original message:
> Reply to message «Re: optwin.vim - setlocal on global options ? ...»,
> sent 00:07:54 31 January 2011, Monday
>
> by Bram Moolenaar:
> > That might find the option window for another window. We need to find
> > the option window that belongs to the current window.
>
> I don't understand you.
>
> :wincmd v
> :options
> :wincmd h
> :options
>
> will bring me to the first option window. If you meant option window on
> other tab, then Marc's code is just fine: bufwinnr() is not able to find
> window on other tab.
>
> > On slow machines opening the option window can be really slow.
> > It can probably be made faster by avoiding too many window-switch
> > commands. I haven't spent time on that.
>
> Then may be you include my patch? It has not changed that
> find-option-window code (just because I forgot about it while writing this
> patch).
>
> > The option window should never be hidden. That needs to be fixed.
>
> augroup OptionWindowDelete
> execute "autocmd! * <buffer=".bufnr('%').">"
> execute "autocmd BufHidden <buffer=".bufnr('%')."> bwipeout!
> ".bufnr('%') augroup END
> just after «new option-window»?
>
> Original message:
> > Marc Weber wrote:
> > > First of all: Why is setlocal aw allowed because its a global option
> > > only.
> >
> > We can have a long discussion about using :setlocal for a global option
> > should fail or not.
> >
> > > I'd like to tidy up optwin.vim and change its output maybe adding core
> > > funtions which can be used to query wether a buf local var has been set
> > > at all.
> > >
> > > I'd like the output to look like this:
> > > === START ==
> > > (g); global option
> > > (b): options belonging to a buffer
> > > (w): options belonging to a window
> > >
> > > You don't assign values to binary options. You set or unset them like
> > > this: set option
> > > set nooption
> >
> > The user would get here to change option values, keep the header as
> > short as possible.
> >
> > I don't think this window should repeat what's in the help files. A
> > line pointing beginners to the help for options would be better.
> >
> > > # shiftwidth (b) number of spaces used for each step of
(auto)indent
> > > (local to buffer) setlocal sw=2
> > >
> > > # autowrite (g) automatically write a file when leaving a modified
> > > buffer set aw
> > >
> > > # ⇧shelltemp (g,b) use a temp file for shell commands instead of
> > > using a pipe setlocal stmp=value1
> > > set stmp="value2" (*)
> > > == END ==
> >
> > When using :set and :setlocal in this way, only for :setlocal we would
> > need to mention whether it's window-local or buffer-local. Otherwise
> > it's global.
> >
> > > So what's different?
> > >
> > > - it shows clearly whether an option is a buffer local, a window
> > > local
> > >
> > > or a global option. The current behaviour is inconsistent. Some
> > > options have a second line saying (local to buffer), but not all
> > > (example "sts")
> > >
> > > - it shows both: global and buffer local vars if they are set.
> > >
> > > (How to query this?)
> > >
> > > Do you know about any reason why not to change the format?
> >
> > It's a compromise between being complete and keeping it short.
> >
> > > It looks like several lines in the file could be improved:
> > > " If there already is an option window, jump to that one.
> > > if bufwinnr("option-window") > 0
> > >
> > > let s:thiswin = winnr()
> > > while 1
> > >
> > > if @% == "option-window"
> > >
> > > finish
> > >
> > > endif
> > > exe "norm! \<C-W>w"
> > > if s:thiswin == winnr()
> > >
> > > break
> > >
> > > endif
> > >
> > > endwhile
> > >
> > > endif
> > >
> > > What the heck does it do? Let's rewrite it:
> > > " If there already is an option window, jump to that one.
> > > if bufwinnr("option-window") > 0
> > >
> > > " if buffer is shown finish even if the buffer whose options should
> > > " be shouwn has different local vars. focus it
> > > exec bufwinnr("option-window").' wincmd w'
> > > finish
> > >
> > > endif
> >
> > That might find the option window for another window. We need to find
> > the option window that belongs to the current window.
> >
> > > Now that you know what this code does you'll notice some issues:
> > >
> > > - if you hide buffer (quit with set hidden) and run options again
> > >
> > > you'll have the options twice
> >
> > The option window should never be hidden. That needs to be fixed.
> >
> > > - if you don't hide and jump to a different buffer which has buffer
> > >
> > > local values set differently those local buffers won't update !
> > >
> > > This makes me think the :options command is close to useless and should
> > > be fixed.
> > >
> > > While the optwin.vim code pays much attention about whether an option
> > > is a local or a global one the output does not reflect this.
> > >
> > > global autowrite output vs local shiftwidth output:
> > > autowrite automatically write a file when leaving a modified
> > > buffer
> > >
> > > set aw noaw
> > >
> > > shiftwidth number of spaces used for each step of (auto)indent
> > >
> > > (local to buffer)
> > >
> > > set sw=10
> > >
> > > Let's have look at the code BinOptionL:
> > > " These functions are called often below. Keep them fast!
> > >
> > > " Init a local binary option
> > > fun! <SID>BinOptionL(name)
> > >
> > > exe "norm! \<C-W>p"
> > > exe "let val = &" . a:name
> > > exe "norm! \<C-W>p"
> > > call append("$", substitute(substitute(" \tset " . val . a:name .
> > > "\t" .
> > >
> > > \!val . a:name, "0", "no", ""), "1", "", ""))
> > >
> > > endfun
> > >
> > > Why is it important to keep it fast - is :options used that often?
> > > why is exe used if there is wincmd p (or even getbufvar ?)
> > > ... some more questions appear but its not worth writing them down.
> >
> > On slow machines opening the option window can be really slow.
> > It can probably be made faster by avoiding too many window-switch
> > commands. I haven't spent time on that.
signature.asc
Description: This is a digitally signed message part.
