As far as I can tell, there are several instances where there are
transitory buffers as vim is starting, opening a new tab, probably
some in closing op.s.
I don't know if I used the right word by saying the buffer is
"undefined", but I don't think it it's guaranteed to be usable until a
certain point, which is after -u, and at the "first file loaded", i.e.
-c
If you open a buffer explicitly from inside .vimtest , then that's a
different story.
It's kinda bug-ish, but it's not a bug unless it's contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
On 5/23/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 5/23/06, Zdenek Sekera <[EMAIL PROTECTED]> wrote:
> > create a file ~/.vimtest as follows:
> >
> > cat > .vimtest
> > set nocompatible
> > set readonly
> > <C-D>
> >
> > and execute (g)vim:
> >
> > vim .vimtest -u .vimtest
> >
> > try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls' in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
----------------- file called 1 ---------------
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo "&readonly=".&readonly
call input('after set readonly 222')
-----------------------------------------------------
In vim, ':verb set readonly?' shows that readonly is misteriously reset.
The output differs between vim6 and vim7.
--------------- vim7 output ------------------
1 % "1" line 1
before set readonly 111
1 % = "1" line 1
&readonly=1
after set readonly 222
----------------------------------------
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
----------------- vim6 output --------------------
1 % "1" line 1
before set readonly 111
before set readonly 111
1 % = "1" line 1
readonly
readonly
&readonly=1
after set readonly 222
-----------------------------------------------------
Looks like a bug to me.
Yakov
