Loading ...
Sorry, an error occurred while loading the content.
 

BufWinEnter triggered too early with -q

Expand Messages
  • Gary Johnson
    I have a plugin that needs to track the line number of the cursor in order to display some information in the status line. The CursorHold event works fine for
    Message 1 of 14 , Feb 16, 2014
      I have a plugin that needs to track the line number of the cursor in
      order to display some information in the status line. The
      CursorHold event works fine for this except when a buffer is first
      opened, as when opening a quickfix error file with -q. I thought
      that I could use the BufWinEnter event to grab the initial line
      number in this case, but it appears to be triggered before the
      quickfix procedure moves the cursor.

      This behavior can be demonstrated as follows. The source file
      main.c contains an error at line 5.

      #include <stdio.h>

      main(int argc, char *argv[])
      {
      exit(0);
      }

      When an error file is generated and opened with Vim's -q option, the
      line number at the time of the BufWinEnter event is 1. I would
      think it would be 5, the line number that the cursor is on when the
      buffer is displayed.

      $ make main > make.out 2>&1
      $ vim -N -u NONE -i NONE --cmd 'au BufWinEnter * let a=line(".")' -c 'let b=line(".")' -q make.out
      :echo a b
      1 5

      Is this a bug? ":help BufWinEnter" says it is triggered "After a
      buffer is displayed in a window." It appears to be triggered before
      the buffer is displayed.

      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Christian Brabandt
      ... I think, what you are seeing is the effect of --cmd which means its arguments will be executed early. In your case when the first empty buffer is entered
      Message 2 of 14 , Feb 17, 2014
        On So, 16 Feb 2014, Gary Johnson wrote:

        > I have a plugin that needs to track the line number of the cursor in
        > order to display some information in the status line. The
        > CursorHold event works fine for this except when a buffer is first
        > opened, as when opening a quickfix error file with -q. I thought
        > that I could use the BufWinEnter event to grab the initial line
        > number in this case, but it appears to be triggered before the
        > quickfix procedure moves the cursor.
        >
        > This behavior can be demonstrated as follows. The source file
        > main.c contains an error at line 5.
        >
        > #include <stdio.h>
        >
        > main(int argc, char *argv[])
        > {
        > exit(0);
        > }
        >
        > When an error file is generated and opened with Vim's -q option, the
        > line number at the time of the BufWinEnter event is 1. I would
        > think it would be 5, the line number that the cursor is on when the
        > buffer is displayed.
        >
        > $ make main > make.out 2>&1
        > $ vim -N -u NONE -i NONE --cmd 'au BufWinEnter * let a=line(".")' -c 'let b=line(".")' -q make.out
        > :echo a b
        > 1 5
        >
        > Is this a bug? ":help BufWinEnter" says it is triggered "After a
        > buffer is displayed in a window." It appears to be triggered before
        > the buffer is displayed.

        I think, what you are seeing is the effect of --cmd which means its
        arguments will be executed early. In your case when the first empty
        buffer is entered and before the errorfile is read in.

        Best,
        Christian
        --
        Now I am depressed ...

        --
        --
        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 vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Gary Johnson
        ... 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
        Message 3 of 14 , Feb 17, 2014
          On 2014-02-17, Christian Brabandt wrote:
          > On So, 16 Feb 2014, Gary Johnson wrote:
          >
          > > I have a plugin that needs to track the line number of the cursor in
          > > order to display some information in the status line. The
          > > CursorHold event works fine for this except when a buffer is first
          > > opened, as when opening a quickfix error file with -q. I thought
          > > that I could use the BufWinEnter event to grab the initial line
          > > number in this case, but it appears to be triggered before the
          > > quickfix procedure moves the cursor.
          > >
          > > This behavior can be demonstrated as follows. The source file
          > > main.c contains an error at line 5.
          > >
          > > #include <stdio.h>
          > >
          > > main(int argc, char *argv[])
          > > {
          > > exit(0);
          > > }
          > >
          > > When an error file is generated and opened with Vim's -q option, the
          > > line number at the time of the BufWinEnter event is 1. I would
          > > think it would be 5, the line number that the cursor is on when the
          > > buffer is displayed.
          > >
          > > $ make main > make.out 2>&1
          > > $ vim -N -u NONE -i NONE --cmd 'au BufWinEnter * let a=line(".")' -c 'let b=line(".")' -q make.out
          > > :echo a b
          > > 1 5
          > >
          > > Is this a bug? ":help BufWinEnter" says it is triggered "After a
          > > buffer is displayed in a window." It appears to be triggered before
          > > the buffer is displayed.
          >
          > I think, what you are seeing is the effect of --cmd which means its
          > arguments will be executed early. In your case when the first empty
          > buffer is entered and before the errorfile is read in.

          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.

          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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Christian Brabandt
          Hi Gary! ... What makes you think, your autocommand shouldn t trigger for the first buffer that is entered? Best, Christian -- Life is to you a dashing and
          Message 4 of 14 , Feb 17, 2014
            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?

            Best,
            Christian
            --
            Life is to you a dashing and bold adventure.

            --
            --
            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 vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Gary Johnson
            Hi Christian, ... 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
            Message 5 of 14 , Feb 17, 2014
              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.

              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 vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Christian Brabandt
              Hi Gary! ... 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
              Message 6 of 14 , Feb 17, 2014
                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.

                Best,
                Christian

                --
                --
                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 vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Gary Johnson
                Hi Christian, ... 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
                Message 7 of 14 , Feb 17, 2014
                  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 <Bram@...>
                  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 vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Christian Brabandt
                  Gary, ... You are correct, I haven t thought about that. One would expect the autocommand to trigger, after the cursor is positioned on the error, but in fact
                  Message 8 of 14 , Feb 18, 2014
                    Gary,

                    Am 2014-02-17 23:52, schrieb Gary Johnson:
                    > 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.

                    You are correct, I haven't thought about that. One would expect the
                    autocommand to trigger, after the cursor is positioned on the error,
                    but in fact it is triggered, when the file is loaded but before the
                    cursor is moved to the error.

                    One could consider this a bug. I am however sure, that once we fix
                    this behaviour, there are many more cases were we need to postpone the
                    BufWinEnter autocommand until the cursor is finally moved to the
                    correct position.

                    But hey, no risk, no fun ;)
                    so here is a patch, that prevents this behaviour in your case.

                    diff --git a/src/quickfix.c b/src/quickfix.c
                    --- a/src/quickfix.c
                    +++ b/src/quickfix.c
                    @@ -1464,6 +1464,9 @@
                    #endif
                    int ok = OK;
                    int usable_win;
                    +#ifdef FEAT_AUTOCMD
                    + char_u *save_ei = NULL;
                    +#endif

                    if (qi == NULL)
                    qi = &ql_info;
                    @@ -1782,6 +1785,13 @@
                    */
                    old_curbuf = curbuf;
                    old_lnum = curwin->w_cursor.lnum;
                    +#ifdef FEAT_AUTOCMD
                    + save_ei = vim_strsave(p_ei);
                    + /* postpone triggering of BufWinEnter autocommand until the cursor
                    is
                    + * positioned at the correct location */
                    + set_string_option_direct((char_u *)"ei", -1, (char_u
                    *)"BufWinEnter",
                    + OPT_FREE, SID_NONE);
                    +#endif

                    if (qf_ptr->qf_fnum != 0)
                    {
                    @@ -1931,6 +1941,15 @@
                    free_string_option(old_swb);
                    }
                    #endif
                    +#ifdef FEAT_AUTOCMD
                    + if (save_ei != NULL)
                    + {
                    + set_string_option_direct((char_u *)"ei", -1, save_ei, OPT_FREE,
                    SID_NONE);
                    + free_string_option(save_ei);
                    + if (ok == OK && curbuf != old_curbuf)
                    + apply_autocmds(EVENT_BUFWINENTER, NULL, NULL, FALSE, curbuf);
                    + }
                    +#endif
                    }

                    /*

                    Best,
                    Christian

                    --
                    --
                    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 vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Gary Johnson
                    ... Thanks very much, Christian! It took me a while to apply your patch because it was corrupted and it took me a while to find the nature of the corruption,
                    Message 9 of 14 , Feb 18, 2014
                      On 2014-02-18, Christian Brabandt wrote:
                      > Gary,
                      >
                      > Am 2014-02-17 23:52, schrieb Gary Johnson:
                      > >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.
                      >
                      > You are correct, I haven't thought about that. One would expect the
                      > autocommand to trigger, after the cursor is positioned on the error,
                      > but in fact it is triggered, when the file is loaded but before the
                      > cursor is moved to the error.
                      >
                      > One could consider this a bug. I am however sure, that once we fix
                      > this behaviour, there are many more cases were we need to postpone the
                      > BufWinEnter autocommand until the cursor is finally moved to the
                      > correct position.
                      >
                      > But hey, no risk, no fun ;)
                      > so here is a patch, that prevents this behaviour in your case.

                      Thanks very much, Christian!

                      It took me a while to apply your patch because it was corrupted and
                      it took me a while to find the nature of the corruption, too. All
                      of the context lines were indented by an extra single space. Once I
                      removed the extra space from those lines, it applied fine.

                      With this patch, Vim passes my example, but the plugin still has the
                      problem of not displaying the right information, so I have some more
                      debugging to do.

                      I try not to apply too many patches to Vim, but I'm now running with
                      five: two of mine and three of yours.

                      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 vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Christian Brabandt
                      ... [...] looks like the patch was a little bit mumbled by the mail, so here it is attached. Best, Christian -- #define struct union /* great space
                      Message 10 of 14 , Feb 18, 2014
                        On Di, 18 Feb 2014, Christian Brabandt wrote:

                        > diff --git a/src/quickfix.c b/src/quickfix.c
                        [...]
                        looks like the patch was a little bit mumbled by the mail, so here it is
                        attached.

                        Best,
                        Christian
                        --
                        <|Rain|> #define struct union /* great space saver */

                        --
                        --
                        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 vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Gary Johnson
                        ... I found the problem. I had been fiddling with the autocommand events in that plugin and had left the troublesome one using BufEnter instead of
                        Message 11 of 14 , Feb 18, 2014
                          On 2014-02-18, Gary Johnson wrote:

                          > With this patch, Vim passes my example, but the plugin still has the
                          > problem of not displaying the right information, so I have some more
                          > debugging to do.

                          I found the problem. I had been fiddling with the autocommand
                          events in that plugin and had left the troublesome one using
                          BufEnter instead of BufWinEnter. Once I corrected that, your patch
                          fixed the original problem!

                          Thank you again,
                          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 vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • Bram Moolenaar
                          ... I don t see where it is mentioned that BufWinEnter gets triggered after positioning the cursor. I don t think we can guarantee that. It s triggered after
                          Message 12 of 14 , Feb 20, 2014
                            Christian Brabandt wrote:

                            > Gary,
                            >
                            > Am 2014-02-17 23:52, schrieb Gary Johnson:
                            > > 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.
                            >
                            > You are correct, I haven't thought about that. One would expect the
                            > autocommand to trigger, after the cursor is positioned on the error,
                            > but in fact it is triggered, when the file is loaded but before the
                            > cursor is moved to the error.
                            >
                            > One could consider this a bug. I am however sure, that once we fix
                            > this behaviour, there are many more cases were we need to postpone the
                            > BufWinEnter autocommand until the cursor is finally moved to the
                            > correct position.
                            >
                            > But hey, no risk, no fun ;)
                            > so here is a patch, that prevents this behaviour in your case.

                            I don't see where it is mentioned that BufWinEnter gets triggered after
                            positioning the cursor. I don't think we can guarantee that. It's
                            triggered after a buffer is loaded into a window. It's supposed to be
                            used for any specific settings you want to apply to the window.

                            I think this patch makes it too complicated.


                            --
                            CUSTOMER: Well, can you hang around a couple of minutes? He won't be
                            long.
                            MORTICIAN: Naaah, I got to go on to Robinson's -- they've lost nine today.
                            CUSTOMER: Well, when is your next round?
                            MORTICIAN: Thursday.
                            DEAD PERSON: I think I'll go for a walk.
                            The Quest for the Holy Grail (Monty Python)

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

                            --
                            --
                            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 vim_dev+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                          • Gary Johnson
                            ... Nothing says explicitly that BufWinEnter gets triggered after the cursor is positioned. I inferred that from After a buffer is displayed in a window
                            Message 13 of 14 , Feb 20, 2014
                              On 2014-02-21, Bram Moolenaar wrote:
                              > Christian Brabandt wrote:
                              >
                              > > Gary,
                              > >
                              > > Am 2014-02-17 23:52, schrieb Gary Johnson:
                              > > > 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.
                              > >
                              > > You are correct, I haven't thought about that. One would expect the
                              > > autocommand to trigger, after the cursor is positioned on the error,
                              > > but in fact it is triggered, when the file is loaded but before the
                              > > cursor is moved to the error.
                              > >
                              > > One could consider this a bug. I am however sure, that once we fix
                              > > this behaviour, there are many more cases were we need to postpone the
                              > > BufWinEnter autocommand until the cursor is finally moved to the
                              > > correct position.
                              > >
                              > > But hey, no risk, no fun ;)
                              > > so here is a patch, that prevents this behaviour in your case.
                              >
                              > I don't see where it is mentioned that BufWinEnter gets triggered after
                              > positioning the cursor. I don't think we can guarantee that. It's
                              > triggered after a buffer is loaded into a window. It's supposed to be
                              > used for any specific settings you want to apply to the window.

                              Nothing says explicitly that BufWinEnter gets triggered after the
                              cursor is positioned. I inferred that from "After a buffer is
                              displayed in a window" since I never see anything displayed in a
                              window until after the cursor has been positioned.

                              > I think this patch makes it too complicated.

                              Is there a method you would recommend for executing a function or
                              otherwise being notified after the cursor is positioned?

                              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 vim_dev+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Gary Johnson
                              ... The particular problem I m having with this plugin seems to occur only when Vim is started with -q and only with the first item in the quickfix list. The
                              Message 14 of 14 , Feb 21, 2014
                                On 2014-02-20, Gary Johnson wrote:
                                > On 2014-02-21, Bram Moolenaar wrote:
                                > > Christian Brabandt wrote:
                                > >
                                > > > Gary,
                                > > >
                                > > > Am 2014-02-17 23:52, schrieb Gary Johnson:
                                > > > > 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.
                                > > >
                                > > > You are correct, I haven't thought about that. One would expect the
                                > > > autocommand to trigger, after the cursor is positioned on the error,
                                > > > but in fact it is triggered, when the file is loaded but before the
                                > > > cursor is moved to the error.
                                > > >
                                > > > One could consider this a bug. I am however sure, that once we fix
                                > > > this behaviour, there are many more cases were we need to postpone the
                                > > > BufWinEnter autocommand until the cursor is finally moved to the
                                > > > correct position.
                                > > >
                                > > > But hey, no risk, no fun ;)
                                > > > so here is a patch, that prevents this behaviour in your case.
                                > >
                                > > I don't see where it is mentioned that BufWinEnter gets triggered after
                                > > positioning the cursor. I don't think we can guarantee that. It's
                                > > triggered after a buffer is loaded into a window. It's supposed to be
                                > > used for any specific settings you want to apply to the window.
                                >
                                > Nothing says explicitly that BufWinEnter gets triggered after the
                                > cursor is positioned. I inferred that from "After a buffer is
                                > displayed in a window" since I never see anything displayed in a
                                > window until after the cursor has been positioned.
                                >
                                > > I think this patch makes it too complicated.
                                >
                                > Is there a method you would recommend for executing a function or
                                > otherwise being notified after the cursor is positioned?

                                The particular problem I'm having with this plugin seems to occur
                                only when Vim is started with -q and only with the first item in the
                                quickfix list. The VimEnter event seems to occur after the cursor
                                is moved, and since I seem to need this event only when Vim is first
                                started, using VimEnter may solve the problem. I'll try that for a
                                while.

                                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 vim_dev+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                              Your message has been successfully submitted and would be delivered to recipients shortly.