On 23/06/12 15:41, Yue Wu wrote:
On Sat, 23 Jun 2012 02:40:12 +0800, Christian Brabandt
<[email protected]> wrote:
Hi Ben!
On Fr, 22 Jun 2012, Ben Fritz wrote:
I can confirm that this happens with the :new command, even if I use
:setlocal instead of :set. However, the subject of this thread implies
that setting the value changes existing buffers. It does not. Only new
buffers do the wrong thing.
I think, the problem is, that when setting the local value, the global
value is also set:
I think local variable should not have this behavior.
[...]
The following is documented and is how Vim always worked (for options
which have a local value):
:setglobal option=value
:setglobal boolopt
:setglobal noboolopt
sets only the global value
:setlocal option=value
:setlocal boolopt
:setlocal noboolopt
sets only the local value
:set option=value
:set boolopt
:set noboolopt
sets both
:set option?
:setlocal option?
displays the local value
:setglobal option?
displays the global value
The question mark may be omitted for options other than boolean options,
but I recommend to always leave it in when querying the value: otherwise
you might unwittingly set a boolean option when you wanted to query it
(and forgot, maybe, that it was boolean).
When creating a new buffer, some local options are copied from the
previous buffer and others are not; the behaviour is not always what I
would have expected: for instance IIRC 'keymap' and 'iminsert' behave
differently from one another. I suppose that Bram might not want to
change long-established (even if quirky) behaviour for fear of breaking
existing scripts, even maybe some third-party scripts not distributed
with Vim.
Best regards,
Tony.
--
"I'd rather have a bottle in front of me than a frontal lobotomy."
--
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
