Hi Marc!
On So, 30 Jan 2011, Marc Weber wrote:
> First of all: Why is setlocal aw allowed because its a global option
> only.
setlocal will set the global option, if the option does not have a local
value.
> 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
>
>
> # 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 ==
>
>
>
> 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 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
>
> 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
>
> - 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?
because the functions are called a lot for all the options available.
> why is exe used if there is wincmd p (or even getbufvar ?)
I guess getbufvar() was not available when optwin.vim was written
originally and getbufvar() is probably also faster than to start jumping
around between windows, since that would trigger autocommands.
> ... some more questions appear but its not worth writing them down.
It sounds like a good idea, to improve the optwin code.
regards,
Christian
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
