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.
