Hi Christian,
On 2014-02-17, Christian Brabandt wrote:
> Hi Gary!
>
> On Mo, 17 Feb 2014, Gary Johnson wrote:
>
> > Hi Christian,
> >
> > On 2014-02-17, Christian Brabandt wrote:
> > > Hi Gary!
> > >
> > > On Mo, 17 Feb 2014, Gary Johnson wrote:
> > >
> > > > Yes, --cmd does execute its arguments early, "before processing any
> > > > vimrc file", but I am using it to define an autocommand. It's the
> > > > timing of the triggering of the autocommand that I think is wrong,
> > > > or at least that I don't understand.
> > >
> > > What makes you think, your autocommand shouldn't trigger for the first
> > > buffer that is entered?
> >
> > I am opening only one buffer in this example. I do think it should
> > trigger for the first buffer.
> >
> > The description of BufWinEnter says that it is triggered "After a
> > buffer is displayed in a window." It is not clear what that means,
> > exactly, in terms of the operations that Vim performs on a buffer in
> > a window. I assume that it means that Vim has finished performing
> > any operations on that window that it is going to before it gives
> > control to the user.
> >
> > When I first see the buffer displayed in the window after executing
> > "vim -q errorfile", the cursor is on the line given in the first
> > error line of 'errorfile'. I would assume that is the line number
> > of the cursor "after [the] buffer is displayed in a window." That
> > would be the value of 'line(".")' at the time that the BufWinEnter
> > event it triggered.
> >
> > What I am seeing instead is that the BufWinEnter event is triggered
> > _before_ the cursor is moved to the first error line. This may be
> > consistent with the meaning of "after [the] buffer is displayed in a
> > window", but it is not very useful.
>
> I think, we have a misunderstanding here (and the documentation isn't
> very clear as you say). The way Vim works is, it first creates an empty
> buffer, when starting.
>
> This is usually useful, after all it's an editor and you usually want to
> edit something, I guess. What's happening in your case is, that Vim
> processes you --cmd and set's up an BufWinEnter autocommand. Then it
> creates an initial window containing an empty buffer (here the
> BufWinEnter autocommand triggers the first time).
>
> Now, Vim notices, that -q <filename> was requested, so Vim proceeds and
> reads in the errorfile (it basically does that similar to what the ex
> command :cfile <argument> does). And then the BufWinEnter autocommand
> triggers again.
>
> You can see this, if you issue :echo bufnr('') and see, how this returns
> 2 instead of 1 and you can even change to that buffer, using :1b
>
> In your particular case, it doesn't make sense to create the initial
> empty buffer, so you might argue, to leave that part out for the
> -q argument. I am however not sure, how well this would work, given that
> autocommands might try to access a buffer and might likely crash Vim if
> there is no buffer. So I think, it's too much a hassle to change the
> existing behaviour and one would only benefit very little but likely
> increase the risk of introducing new bugs.
>
> Note, I haven't checked the code closely, so perhaps such a change is
> easily possible.
Thanks for your patience with this and willingness to work it
through. I think we're still not on the same page, however.
In my example I use the following autocommand:
au BufWinEnter * let a=line(".")
Let us assume that you are correct that this autocommand triggers
twice, once for the creation of buffer 1 and once for the creation
of buffer 2. After the creation of buffer 2, 'a' should contain the
value of some line number in buffer 2.
That is what I want. I want the number of the cursor line in buffer
2 after it is displayed. My point is that I think it should be the
line number of the cursor when the buffer is displayed in the
window, not the line number of the cursor when the buffer is first
opened.
I also tried an experiment to see if you were correct about the
number of times BufWinEnter is triggered. You are. I executed the
following.
$ vim -N -u NONE -i NONE --cmd 'au BufWinEnter * echomsg "Line" line(".")'
-q make.out
:messages
Messages maintainer: Bram Moolenaar <[email protected]>
Line 1
"main.c" 6L, 66C
Line 1
(3 of 3): warning: incompatible implicit declaration of built-in function
‘exit’
(3 of 3): warning: incompatible implicit declaration of built-in function
‘exit’
Press ENTER or type command to continue
Regards,
Gary
--
--
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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
