Re: set readonly - strange?
Yakov Lerner wrote: In case you can't reproduce it, Bram, I' attaching the output with all escape sequences. The output was taken using vim -u /tmp/1 /tmp/1 | tee /tmp/output It clearly shows how the three delayed 'readonly readonly readonly' are printed *afer* vim uninitialized the screen mode. I hope this helps to understand what happens. It doesn't happen for me, thus something in your setup must somehow change it. I see the readonly in the right place, both for Vim 6 and Vim 7. -- With sufficient thrust, pigs fly just fine. -- RFC 1925 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: set readonly - strange?
On 6/19/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
After the following patch, the output is better. Two out of
three 'readonly' lines are now in place.
--- message.c.000 2006-06-19 02:49:34.0 +0300
+++ message.c 2006-06-19 02:52:41.0 +0300
@@ -2767,6 +2767,7 @@
)
{
printf(%s, str);
+fflush(stdout);
return;
}
# endif
It doesn't happen for me, thus something in your setup must somehow
change it. I see the readonly in the right place, both for Vim 6 and
Vim 7.
Bram,
Strange. Is stdout unbuffered on your OS ?
On Linux/glibc, stdout is line-buffered (but stderr is unbuffered).
I think this is per posix.
The the following test
#include stdio.h
main() {
printf(readonly ); fprintf(stderr,before delay\n);
sleep(4); return 0;
}
prints the following on Linux:
before delay
readonly
because stdout is line-buffered (flushed on exit in this case).
Does it print readonly before delay on your OS ? That would
mean that stdout is totally unbuffered on your OS unlike on Linux.
Yakov
Re: set readonly - strange?
On 6/18/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Yakov Lerner 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 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
For me the readonly output is there. I don't know why you don't get it.
The file is loaded after sourcing the file. Try putting a getline(3) in
your vim script. You will see that the file is not loaded yet. Thus
the buffer exists but doesn't contain the file text yet.
'readonly' is set according to the file edited. If you want to set it,
you need to use something like:
vim file +set readonly
The + arguments are done after loading the file.
It was already like this in Vim 6.0. I don't know why you say it
differs between vim 6 and vim 7.
I say 'it differs' because it differs. For vim6, all 'readonly's appear
where they are supposed to be. For vim7 (taken today from svn, 7.0.17),
however, the output still has three 'readonly's missing ...
However at closer inspection, I found them lost-and-found 'readonly's
appearing after I exited vim, as if they were buffered
somewhere, and then flushed at vim's exit, misplaced.
Here is how it looks for me:
[EMAIL PROTECTED] src]$ ./vim -u /tmp/1 /tmp/1
- 1st 'readonly' is missing here
1 %/tmp/1 line 1
before set readonly 111
1 % = /tmp/1 line 1
- 2nd 'readonly' is missing here
- 3rd 'readonly' is missing here
readonly=1
Press ENTER or type command to continue
- I pressed ZZ here to quit
readonly readonly [EMAIL PROTECTED] src]$
^^
the three missing 'readonly's misteriously surfaced here,
only after vim quit! This is FedoraCore 5
Maybe it has to do with $TERM ? The TERM is xterm,
and terminal is xterm or konsole (same result):
Yakov
Re: set readonly - strange?
Yakov Lerner wrote:
On 6/18/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Yakov Lerner 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 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
For me the readonly output is there. I don't know why you don't get
it.
The file is loaded after sourcing the file. Try putting a getline(3) in
your vim script. You will see that the file is not loaded yet. Thus
the buffer exists but doesn't contain the file text yet.
'readonly' is set according to the file edited. If you want to set it,
you need to use something like:
vim file +set readonly
The + arguments are done after loading the file.
It was already like this in Vim 6.0. I don't know why you say it
differs between vim 6 and vim 7.
I say 'it differs' because it differs. For vim6, all 'readonly's appear
where they are supposed to be. For vim7 (taken today from svn, 7.0.17),
however, the output still has three 'readonly's missing ...
However at closer inspection, I found them lost-and-found 'readonly's
appearing after I exited vim, as if they were buffered
somewhere, and then flushed at vim's exit, misplaced.
Here is how it looks for me:
[EMAIL PROTECTED] src]$ ./vim -u /tmp/1 /tmp/1
- 1st 'readonly' is missing here
1 %/tmp/1 line 1
before set readonly 111
1 % = /tmp/1 line 1
- 2nd 'readonly' is missing here
- 3rd 'readonly' is missing here
readonly=1
Press ENTER or type command to continue
- I pressed ZZ here to quit
readonly readonly [EMAIL PROTECTED] src]$
^^
the three missing 'readonly's misteriously surfaced here,
only after vim quit! This is FedoraCore 5
Maybe it has to do with $TERM ? The TERM is xterm,
and terminal is xterm or konsole (same result):
Yakov
I confirm this behaviour on
VIM - Vi IMproved 7.0 (2006 May 7, compiled Jun 4 2006 08:37:52)
Included patches: 1-17
Compiled by [EMAIL PROTECTED]
Huge version with GTK2 GUI. Features included (+) or not (-):
[...]
running in konsole on Novell-SuSE Professional 9.3.
With the same executable in GUI mode the three readonly messages
appear in their proper places in a popup window.
In console mode, but not in GUI mode, Enter must be hit after before
set readonly 111 and again after after set readonly 222.
Best regards,
Tony.
Re: set readonly - strange?
On 6/18/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 6/18/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Yakov Lerner 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 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
For me the readonly output is there. I don't know why you don't get it.
The file is loaded after sourcing the file. Try putting a getline(3) in
your vim script. You will see that the file is not loaded yet. Thus
the buffer exists but doesn't contain the file text yet.
'readonly' is set according to the file edited. If you want to set it,
you need to use something like:
vim file +set readonly
The + arguments are done after loading the file.
It was already like this in Vim 6.0. I don't know why you say it
differs between vim 6 and vim 7.
I say 'it differs' because it differs. For vim6, all 'readonly's appear
where they are supposed to be. For vim7 (taken today from svn, 7.0.17),
however, the output still has three 'readonly's missing ...
However at closer inspection, I found them lost-and-found 'readonly's
appearing after I exited vim, as if they were buffered
somewhere, and then flushed at vim's exit, misplaced.
Here is how it looks for me:
[EMAIL PROTECTED] src]$ ./vim -u /tmp/1 /tmp/1
- 1st 'readonly' is missing here
1 %/tmp/1 line 1
before set readonly 111
1 % = /tmp/1 line 1
- 2nd 'readonly' is missing here
- 3rd 'readonly' is missing here
readonly=1
Press ENTER or type command to continue
- I pressed ZZ here to quit
readonly readonly [EMAIL PROTECTED] src]$
^^
the three missing 'readonly's misteriously surfaced here,
only after vim quit! This is FedoraCore 5
Maybe it has to do with $TERM ? The TERM is xterm,
and terminal is xterm or konsole (same result):
In case you can't reproduce it, Bram, I' attaching the output
with all escape sequences. The output was taken using
vim -u /tmp/1 /tmp/1 | tee /tmp/output
It clearly shows how the three delayed 'readonly readonly readonly'
are printed *afer* vim uninitialized the screen mode.
I hope this helps to understand what happens.
Yakov
Yakov
output_with_escape_sequences
Description: Binary data
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
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.
That may be true, but...
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.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
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.
I also think it is bug.
---Zdenek
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 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
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.
That may be true, but...
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.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro command is
read according to the -u option, though it might exist in some form
since no error occurs. Even if a buffer does exist at that time, I'm
fairly sure that is was transitory, and that it's not the same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage, where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro? , but that's
not the same as when the -u file is processed.
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.
I also think it is bug.
---Zdenek
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 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 11:21
To: Zdenek Sekera
Cc: Yakov Lerner; vim-dev@vim.org
Subject: Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
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.
That may be true, but...
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.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro command is
read according to the -u option, though it might exist in some form
since no error occurs. Even if a buffer does exist at that time, I'm
fairly sure that is was transitory, and that it's not the same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage, where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro? , but that's
not the same as when the -u file is processed.
I don't know to that depth as you do, but then we should
agree that 'set readonly' in .vimrc is useless, because
it would never work, right?
This is hard to accept. So it looks more and more just as a bug.
---Zdenek
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.
I also think it is bug.
---Zdenek
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 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 12:38
To: Zdenek Sekera
Cc: vim-dev@vim.org
Subject: Re: set readonly - strange?
I think 'readonly' does not belong in the .vimrc since it is a
buffer-local-only option.
Yes, but I have only one buffer...
However, you can use an autocommand to set it. What are you really
trying to do from the .vimrc ? Setting the readonly value for the
default empty starting buffer seems odd, and you can manage the
reaonly property several ways for files actually loaded into buffers.
Clearly, my example was a case simplyfied to the utmost,
but describing what I really want to do: display a buffer
for reading only. My real '.vimtest' has many more options,
of course, so I thought I can this one into it as well
(just as I wanted 'modifiable', 'modified', and more).
This was to make things simple, start 'vim -u this that'.
Since that doesn't work for some of those settings, I'll
have to settle for another way like 'vim -R ...'.
I wanted to avoid any additional parameter on the vim call
(for some reasons), but I have to now change my mind.
You maybe right it doesn't belong to '.vimrc', but that's
not explicitly stated anywhere (and for others), hence
my trying and discovering a hole, perhaps a bug.
Wouldn't you think that it should apply always to at least
the first buffer on the vim call? Or all if it's in .vimrc?
The implementation is not clear IMHO, perhaps the doc needs
some update.
It will be indeed interesting to see what will Bram decide
about it. Let's wait.
---Zdenek
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 11:21
To: Zdenek Sekera
Cc: Yakov Lerner; vim-dev@vim.org
Subject: Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
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.
That may be true, but...
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.
In my test case, buffer must exist, I am well passed
the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro
command is
read according to the -u option, though it might exist in
some form
since no error occurs. Even if a buffer does exist at
that time, I'm
fairly sure that is was transitory, and that it's not the
same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage,
where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro?
, but that's
not the same as when the -u file is processed.
I don't know to that depth as you do, but then we should
agree that 'set readonly' in .vimrc is useless, because
it would never work, right?
This is hard to accept. So it looks more and more just as a bug.
---Zdenek
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.
I also think it is bug.
---Zdenek
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
Re: set readonly - strange?
On 5/24/06, Eric Arnold [EMAIL PROTECTED] wrote: I think 'readonly' does not belong in the .vimrc since it is a buffer-local-only option. If you try to set any other buffer-local option in .vimrc, you'll see that it works just fine. I tried 'set tw=22' in file opened as 'vim -u file file' and it works just fine. Yakov
Re: set readonly - strange?
On 5/24/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 5/24/06, Eric Arnold [EMAIL PROTECTED] wrote: I think 'readonly' does not belong in the .vimrc since it is a buffer-local-only option. If you try to set any other buffer-local option in .vimrc, you'll see that it works just fine. I tried 'set tw=22' in file opened as 'vim -u file file' and it works just fine. True. Don't know for sure exactly what's going on. However, if you use: set nocp echomsg '1 bufnr ' . bufnr(%) . ', bufname ' . bufname( bufnr(%) ) echomsg '1 bufloaded ' . bufloaded( bufnr(%) ) edit somefile echomsg '2 bufnr ' . bufnr(%) . ', bufname ' . bufname( bufnr(%) ) echomsg '2 bufloaded ' . bufloaded( bufnr(%) ) set tw=71 set ro The first echomsg shows that it does indeed think that the file from the command line is in a buffer, however, bufloaded() shows that it isn't loaded. For all I can tell, the first buffer was created by :badd and doesn't become loaded until .vimrc is finished (and maybe even later). So, there must be some difference about which options can be applied to a buffer before it is loaded.
Re: set readonly - strange?
I wouldn't expect that to work. There is no defined loaded buffer when the -u vimrc is run. 'readonly' is local to buffers only, so in your example, it has no buffer to be applied to. If you want everything to be readonly, try setting a BufEnter autocommand. If you want just one file to be readonly, try setting the mode line. Also consider: gvimd -c 'so .vimtest' .vimtest 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'. Looks strange at the minimum, bug? ---Zdenek
Re: set readonly - strange?
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 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
