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.
--
"Hit any key to continue" is very confusing when you have two keyboards.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
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
