[Bug] 'iminsert' isn't a buffer variable as it should be

[Yue Wu]

Hi, list,

As the title, :setlocal iminsert=1 in a buffer will make the value of it
in all other buffers to be 1 too.

From the help of 'iminsert', it should be a buffer variable. So I think
it's a bug.

Please confirm it, thank you.

--
Regards,
Yue Wu

State Key laboratory of Natural Products and Functions
Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China

[Yue Wu]

[Yue Wu]

[Bram Moolenaar]

Yue Wu wrote:

> As the title, :setlocal iminsert=1 in a buffer will make the value of it
> in all other buffers to be 1 too.
>
> From the help of 'iminsert', it should be a buffer variable. So I think
> it's a bug.
>
> Please confirm it, thank you.

I don't see this. Please check if you have any scripts that matter. If
the problem persists give us the sequence of commands that shows the
problem, starting with "vim -u NONE".

--
Never overestimate a man's ability to underestimate a woman.

/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///

[Taylor Hedberg]

Yue Wu, Wed 2012-06-20 @ 15:21:13+0800:

> Please confirm it, thank you.

I cannot reproduce this with Vim 7.3.556 on Linux.

[Yue Wu]

On Wed, 20 Jun 2012 17:55:16 +0800, Bram Moolenaar <Br...@moolenaar.net>
wrote:

>
> Yue Wu wrote:
>
>> As the title, :setlocal iminsert=1 in a buffer will make the value of it
>> in all other buffers to be 1 too.
>>
>> From the help of 'iminsert', it should be a buffer variable. So I
>> think
>> it's a bug.
>>

>> Please confirm it, thank you.
>

> I don't see this. Please check if you have any scripts that matter. If
> the problem persists give us the sequence of commands that shows the
> problem, starting with "vim -u NONE".
>

I'm runing gvim on windows xp sp3. To reproduce:

gvim.exe -u NONE
:set nocp

:set iminsert?
> It should produce 0.

:set iminsert=1

:new
> To start a new buffer

:set iminsert?

it will show iminsert is 1, it should be 0.

:version

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:56:10)
MS-Windows 32-bit GUI version
Included patches: 1-46
Compiled by Bram@KIBAALE
Big version with GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +conceal +cryptv
+cscope +cursorbind +cursorshape +dialog_con_gui +diff +digraphs -dnd
-ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path +float +folding
-footer +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist
+keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua
+menu +mksession
+modify_fname +mouse +mouseshape +multi_byte +multi_lang -mzscheme
+netbeans_intg -ole -osfiletype +path_extra -perl +persistent_undo
-postscript +printer -profile -python
-python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax
+tag_binary +tag_old_static
-tag_any_white -tcl -tgetent -termresponse +textobjects +title +toolbar
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore
+wildmenu +windows +writebackup -xfontset -xim -xterm_save -xpm_w32
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32
-DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DWINVER=0x0400
-D_WIN32_WINNT=0x0400 /Fo.\ObjG/ /Ox /GL -DNDEBUG /Zl /MT -DFEAT_GUI_W32
-DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_BIG /Fd.\ObjG/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS
oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib
ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib version.lib
winspool.lib comctl32.lib advapi32.lib shell32.lib /machine:i386
/nodefaultlib libcmt.lib user32.lib WSock32.lib /PDB:gvim.pdb
-debu

[Yue Wu]

Hi, I don't know if the mail has been reached to the list, so I do a reply
of it.

[Tony Mechelynck]

On 22/06/12 04:09, Yue Wu wrote:
[...]

> Hi, I don't know if the mail has been reached to the list, so I do a
> reply of it.
>

It did. Don't you read the list? Or you could have found it on Google
Groups.

The probable reason no one replied is that no one had anything of value
to contribute.


Best regards,
Tony.
--
A witty saying proves nothing, but saying something pointless gets
people's attention.

[Yue Wu]

On Fri, 22 Jun 2012 14:58:15 +0800, Tony Mechelynck wrote:

> On 22/06/12 04:09, Yue Wu wrote:
> [...]
>> Hi, I don't know if the mail has been reached to the list, so I do a
>> reply of it.
>>
>
> It did. Don't you read the list? Or you could have found it on Google
> Groups.
>
> The probable reason no one replied is that no one had anything of value
> to contribute.
>
>
> Best regards,
> Tony.

Thank you, I should check it on Google Groups, but I have internet access
restriction on China mainland, will wait for any response, and sorry for
noise ;p

[Ben Fritz]

On Wednesday, June 20, 2012 8:35:00 AM UTC-5, Yue Wu wrote:
>
> I'm runing gvim on windows xp sp3. To reproduce:
>
> gvim.exe -u NONE
> :set nocp
>
> :set iminsert?
> > It should produce 0.
>
> :set iminsert=1
>
> :new
> > To start a new buffer
>
> :set iminsert?
>
> it will show iminsert is 1, it should be 0.
>

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.

:help local-options

> When splitting a window, the local options are copied to the new window. Thus
> right after the split the contents of the two windows look the same.

> When editing a new buffer, its local option values must be initialized. Since
> the local options of the current buffer might be specifically for that buffer,
> these are not used. Instead, for each buffer-local option there also is a
> global value, which is used for new buffers. With ":set" both the local and
> global value is changed. With "setlocal" only the local value is changed,
> thus this value is not used when editing a new buffer.

I'm seeing the behavior for split windows, not the behavior for new buffers, when I use :new, even if I use :new with a filename.

:e newfilename also does not initialize the value of 'iminsert' to the global value, it keeps the same value as the previous buffer.

[Christian Brabandt]

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:

,----[ set_num_option(...) ]-
| [...]
| else if (pp == &curbuf->b_p_iminsert)
| {
| if (curbuf->b_p_iminsert < 0 || curbuf->b_p_iminsert > B_IMODE_LAST)
| {
| curbuf->b_p_iminsert = B_IMODE_NONE;
| }
| p_iminsert = curbuf->b_p_iminsert;
| [...]
`----

But I am not sure, whether this is a bug or just a documentation issue.

regards,
Christian

[Yue Wu]

On Sat, 23 Jun 2012 02:40:12 +0800, Christian Brabandt
<cbl...@256bit.org> 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.

>
> ,----[ set_num_option(...) ]-
> | [...]
> | else if (pp == &curbuf->b_p_iminsert)
> | {
> | if (curbuf->b_p_iminsert < 0 || curbuf->b_p_iminsert >
> B_IMODE_LAST)
> | {
> | curbuf->b_p_iminsert = B_IMODE_NONE;
> | }
> | p_iminsert = curbuf->b_p_iminsert;
> | [...]
> `----
>
> But I am not sure, whether this is a bug or just a documentation issue.
>
> regards,
> Christian
>

[Tony Mechelynck]

On 23/06/12 15:41, Yue Wu wrote:
> On Sat, 23 Jun 2012 02:40:12 +0800, Christian Brabandt
> <cbl...@256bit.org> 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."

[Christian Brabandt]

Hi Tony!

On So, 24 Jun 2012, Tony Mechelynck wrote:

> :setlocal option=value
> :setlocal boolopt
> :setlocal noboolopt
> sets only the local value

Except, that for iminsert this also sets the global option.

regards,
Christian
--

[Tony Mechelynck]

Ben Fritz said the behaviour is correct for already existing buffers. I
think what happened here is what I mentioned lower down in the part you
snipped.


Best regards,
Tony.
--
"There's nothing wrong with teenagers that reasoning with them won't
aggravate."

[Ben Fritz]

On Sunday, June 24, 2012 7:06:39 AM UTC-5, Tony Mechelynck wrote:
> On 24/06/12 13:41, Christian Brabandt wrote:
> > Hi Tony!
> >
> > On So, 24 Jun 2012, Tony Mechelynck wrote:
> >
> >> :setlocal option=value
> >> :setlocal boolopt
> >> :setlocal noboolopt
> >> sets only the local value
> >
> > Except, that for iminsert this also sets the global option.
> >
> > regards,
> > Christian
> >
> Ben Fritz said the behaviour is correct for already existing buffers. I
> think what happened here is what I mentioned lower down in the part you
> snipped.
>
>

Nope, the option is not getting copied from the buffer on creating a new buffer.

It is getting set from the global option as documented.

However, the global option is being incorrectly set when using :setlocal.

gvim -N -i NONE -u NONE
:set iminsert?
2
:new
:setlocal iminsert=1
:set iminsert?
1
:wincmd w
:set iminsert?
2
:new
:set iminsert?
1

[Tony Mechelynck]

On 24/06/12 20:52, Ben Fritz wrote:
> On Sunday, June 24, 2012 7:06:39 AM UTC-5, Tony Mechelynck wrote:
>> On 24/06/12 13:41, Christian Brabandt wrote:
>>> Hi Tony!
>>>
>>> On So, 24 Jun 2012, Tony Mechelynck wrote:
>>>
>>>> :setlocal option=value
>>>> :setlocal boolopt
>>>> :setlocal noboolopt
>>>> sets only the local value
>>>
>>> Except, that for iminsert this also sets the global option.
>>>
>>> regards,
>>> Christian
>>>
>> Ben Fritz said the behaviour is correct for already existing buffers. I
>> think what happened here is what I mentioned lower down in the part you
>> snipped.
>>
>>
>
> Nope, the option is not getting copied from the buffer on creating a new buffer.
>
> It is getting set from the global option as documented.
>
> However, the global option is being incorrectly set when using :setlocal.

Ah, sorry. I did the tests below myself and I get the same results as you do

>
> gvim -N -i NONE -u NONE
> :set iminsert?
> 2

iminsert=2
:setg imi?
iminsert=2

> :new
> :setlocal iminsert=1
> :set iminsert?
> 1

iminsert=1
:setg imi?
iminsert=1 <== this shows the bug

> :wincmd w
> :set iminsert?
> 2

iminsert=2
:setg imi?
iminsert=1 <== and yet, this is not a global option: in this
particular case, we see a local setting
different from the global setting
> :new
> :set iminsert?
> 1
iminsert=1
:setg imi?
iminsert=1
:setl imi=2
:setg imi?
iminsert=2 <== the bug, again
:setl imi=0
:setg imi?
iminsert=0

The above shows that it is possible to display different values with
:setl imi? and :setg imi? in the same buffer, but that :setl imi=value
(with "value" being 0, 1 or 2) also sets the global setting to the same
value.

I'm using gvim (Huge) version 7.3.566 with GTK2/Gnome2 GUI.


Best regards,
Tony.
--
Drugs may be the road to nowhere, but at least they're the scenic
route!

[Christian Brabandt]

Hi Tony!

On Mo, 25 Jun 2012, Tony Mechelynck wrote:

> The above shows that it is possible to display different values with
> :setl imi? and :setg imi? in the same buffer, but that :setl
> imi=value (with "value" being 0, 1 or 2) also sets the global
> setting to the same value.
>

That's was I have said several mails before ;)
I even showed the code, that was responsible for this.

regards,
Christian
--
Die Kunst wird immer sensationeller und unverst�ndlicher und das Leben
immer langweiliger und hoffnungsloser.
-- Henry Miller