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

Re: Each buffer in own tab/function lookup seem to clash

Expand Messages
  • Ben Fritz
    ... Ok, so if you re not setting position on a BufRead, then your BufAdd autocmd causes the file to open in a new tab. But Vim loses track of the fact that it
    Message 1 of 11 , Oct 1, 2013
    • 0 Attachment
      On Tuesday, October 1, 2013 12:24:02 AM UTC-5, Henry Combrinck wrote:
      > > It seems like the BuffAdd event fires before the file is actually read
      > > into the buffer. For after the file gets read, there is the BufRead
      > > event. So, your autocmd to force new buffers into tabs is messing with
      > > window layout and all sorts of things before Vim has any text to jump to
      > > to find the tag. Without any more details, I'd suggest trying a few
      > > other buffer related events, trying to get one which happens as late as
      > > possible in the process of opening the buffer so it has less chance of
      > > interfering with commands in progress.
      > >
      > > If that doesn't work, you could try modifying your MatchCaseTag function
      > > to issue a second tjump command in case the first doesn't work. It's a
      > > hack, but maybe it will fix your problem.
      > >
      > > Other than that, I think we need more info. Is there a pattern to the
      > > location in the new file where the bad tag jump takes you? Is it the
      > > last edited position, restored by your BufReadPost autocmd? Is it the
      > > same line number as the file you're jumping from, but in the new file?
      > > Somewhere else? No discernible pattern at all? This may give some clues.
      > > You can also try removing that BufReadPost autocmd temporarily to see
      > > whether it plays into this problem. I know you want to keep that one,
      > > but perhaps it needs tweaking to not fire while doing a tag jump via
      > > your function.
      >
      > If I disable BufReadPost, then this is what happens:
      >
      > C-] on a function call (A) in file (1) opens a new tab, but positions the
      > cursor at the top of file (2), not on the function declaration itself.
      >

      Ok, so if you're not setting position on a BufRead, then your BufAdd autocmd
      causes the file to open in a new tab. But Vim loses track of the fact that
      it is in the middle of jumping somewhere. Probably this is because you're
      messing with windows and such before Vim even reads in the buffer contents.

      > If I then close the tab (returning to the original file (1)), and hit C-]
      > again (on the same function call (A)), it then jumps to file (2) correctly
      > positioning the cursor on the function declaration, but interestingly,
      > does not open file (2) in a new tab, but instead re-uses the existing one
      > (as it would if the function declaration was in the same file).

      I bet this is because the buffer is already in your buffer list, so BufAdd
      doesn't fire. How did you close the tab? You can try using :bdelete or
      :bwipe instead of :tabclose or :close or :quit to see if that makes a
      difference. But I think BufAdd is just the wrong event to use for this
      autocmd, because it causes this problem and also potentially the problem
      with interrupting a tag jump.

      >
      > If enable BufReadPost, but disable au BufAdd,BufNewFile..., then all works
      > perfectly, but without tabs obviously.
      >

      I think instead of BuffAdd, I'd first try BufWinEnter. If that doesn't work,
      then maybe BufReadPost would work.

      --
      --
      You received this message from the "vim_use" 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_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Henry Combrinck
      ... I normally close the tab with :q, but :bdelete and :bwipe do the same. ... Spent some time brushing up on events at
      Message 2 of 11 , Oct 1, 2013
      • 0 Attachment
        On Tuesday, October 1, 2013 5:18:59 PM UTC+2, Ben Fritz wrote:
        > On Tuesday, October 1, 2013 12:24:02 AM UTC-5, Henry Combrinck wrote:
        > > > It seems like the BuffAdd event fires before the file is actually read
        > > > into the buffer. For after the file gets read, there is the BufRead
        > > > event. So, your autocmd to force new buffers into tabs is messing with
        > > > window layout and all sorts of things before Vim has any text to jump to
        > > > to find the tag. Without any more details, I'd suggest trying a few
        > > > other buffer related events, trying to get one which happens as late as
        > > > possible in the process of opening the buffer so it has less chance of
        > > > interfering with commands in progress.
        > > >
        > > > If that doesn't work, you could try modifying your MatchCaseTag function
        > > > to issue a second tjump command in case the first doesn't work. It's a
        > > > hack, but maybe it will fix your problem.
        > > >
        > > > Other than that, I think we need more info. Is there a pattern to the
        > > > location in the new file where the bad tag jump takes you? Is it the
        > > > last edited position, restored by your BufReadPost autocmd? Is it the
        > > > same line number as the file you're jumping from, but in the new file?
        > > > Somewhere else? No discernible pattern at all? This may give some clues.
        > > > You can also try removing that BufReadPost autocmd temporarily to see
        > > > whether it plays into this problem. I know you want to keep that one,
        > > > but perhaps it needs tweaking to not fire while doing a tag jump via
        > > > your function.
        > >
        > > If I disable BufReadPost, then this is what happens:
        > >
        > > C-] on a function call (A) in file (1) opens a new tab, but positions the
        > > cursor at the top of file (2), not on the function declaration itself.
        > >
        >
        > Ok, so if you're not setting position on a BufRead, then your BufAdd autocmd
        > causes the file to open in a new tab. But Vim loses track of the fact that
        > it is in the middle of jumping somewhere. Probably this is because you're
        > messing with windows and such before Vim even reads in the buffer contents.
        >
        > > If I then close the tab (returning to the original file (1)), and hit C-]
        > > again (on the same function call (A)), it then jumps to file (2) correctly
        > > positioning the cursor on the function declaration, but interestingly,
        > > does not open file (2) in a new tab, but instead re-uses the existing one
        > > (as it would if the function declaration was in the same file).
        >
        > I bet this is because the buffer is already in your buffer list, so BufAdd
        > doesn't fire. How did you close the tab? You can try using :bdelete or
        > :bwipe instead of :tabclose or :close or :quit to see if that makes a
        > difference. But I think BufAdd is just the wrong event to use for this
        > autocmd, because it causes this problem and also potentially the problem
        > with interrupting a tag jump.

        I normally close the tab with :q, but :bdelete and :bwipe do the same.

        > >
        > > If enable BufReadPost, but disable au BufAdd,BufNewFile..., then all works
        > > perfectly, but without tabs obviously.
        > >
        >
        > I think instead of BuffAdd, I'd first try BufWinEnter. If that doesn't work,
        > then maybe BufReadPost would work.

        Spent some time brushing up on events at
        http://vimdoc.sourceforge.net/htmldoc/autocmd.html#{event}

        Sadly, "au BufWinEnter * nested tab sball" results in the error
        "E435: Couldn't find tag, just guessing"

        And so does "au BufReadPost * nested tab sball"

        At times like this I wish I could slip into an alternate universe for a few weeks or months and study the problem to the exclusion of all else in as much depth as required until a solution is found, then return to "now" where my eyelids have yet to complete their last lubricating blink and be hailed an all-knowing demi god.

        oh well.

        --
        --
        You received this message from the "vim_use" 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_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • zvavashe@...
        -original message- Subject: Re: Each buffer in own tab/function lookup seem to clash From: Henry Combrinck Date: 02/10/2013 8:08 am
        Message 3 of 11 , Oct 2, 2013
        • 0 Attachment
          -original message-
          Subject: Re: Each buffer in own tab/function lookup seem to clash
          From: Henry Combrinck <henrylcombrinck@...>
          Date: 02/10/2013 8:08 am

          On Tuesday, October 1, 2013 5:18:59 PM UTC+2, Ben Fritz wrote:
          > On Tuesday, October 1, 2013 12:24:02 AM UTC-5, Henry Combrinck wrote:
          > > > It seems like the BuffAdd event fires before the file is actually read
          > > > into the buffer. For after the file gets read, there is the BufRead
          > > > event. So, your autocmd to force new buffers into tabs is messing with
          > > > window layout and all sorts of things before Vim has any text to jump to
          > > > to find the tag. Without any more details, I'd suggest trying a few
          > > > other buffer related events, trying to get one which happens as late as
          > > > possible in the process of opening the buffer so it has less chance of
          > > > interfering with commands in progress.
          > > >
          > > > If that doesn't work, you could try modifying your MatchCaseTag function
          > > > to issue a second tjump command in case the first doesn't work. It's a
          > > > hack, but maybe it will fix your problem.
          > > >
          > > > Other than that, I think we need more info. Is there a pattern to the
          > > > location in the new file where the bad tag jump takes you? Is it the
          > > > last edited position, restored by your BufReadPost autocmd? Is it the
          > > > same line number as the file you're jumping from, but in the new file?
          > > > Somewhere else? No discernible pattern at all? This may give some clues.
          > > > You can also try removing that BufReadPost autocmd temporarily to see
          > > > whether it plays into this problem. I know you want to keep that one,
          > > > but perhaps it needs tweaking to not fire while doing a tag jump via
          > > > your function.
          > >
          > > If I disable BufReadPost, then this is what happens:
          > >
          > > C-] on a function call (A) in file (1) opens a new tab, but positions the
          > > cursor at the top of file (2), not on the function declaration itself.
          > >
          >
          > Ok, so if you're not setting position on a BufRead, then your BufAdd autocmd
          > causes the file to open in a new tab. But Vim loses track of the fact that
          > it is in the middle of jumping somewhere. Probably this is because you're
          > messing with windows and such before Vim even reads in the buffer contents.
          >
          > > If I then close the tab (returning to the original file (1)), and hit C-]
          > > again (on the same function call (A)), it then jumps to file (2) correctly
          > > positioning the cursor on the function declaration, but interestingly,
          > > does not open file (2) in a new tab, but instead re-uses the existing one
          > > (as it would if the function declaration was in the same file).
          >
          > I bet this is because the buffer is already in your buffer list, so BufAdd
          > doesn't fire. How did you close the tab? You can try using :bdelete or
          > :bwipe instead of :tabclose or :close or :quit to see if that makes a
          > difference. But I think BufAdd is just the wrong event to use for this
          > autocmd, because it causes this problem and also potentially the problem
          > with interrupting a tag jump.

          I normally close the tab with :q, but :bdelete and :bwipe do the same.

          > >
          > > If enable BufReadPost, but disable au BufAdd,BufNewFile..., then all works
          > > perfectly, but without tabs obviously.
          > >
          >
          > I think instead of BuffAdd, I'd first try BufWinEnter. If that doesn't work,
          > then maybe BufReadPost would work.

          Spent some time brushing up on events at
          http://vimdoc.sourceforge.net/htmldoc/autocmd.html#{event}

          Sadly, "au BufWinEnter * nested tab sball" results in the error
          "E435: Couldn't find tag, just guessing"

          And so does "au BufReadPost * nested tab sball"

          At times like this I wish I could slip into an alternate universe for a few weeks or months and study the problem to the exclusion of all else in as much depth as required until a solution is found, then return to "now" where my eyelids have yet to complete their last lubricating blink and be hailed an all-knowing demi god.

          oh well.

          --
          --
          You received this message from the "vim_use" 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_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.

          --
          --
          You received this message from the "vim_use" 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_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Ben Fritz
          ... Does the suggested workaround of issuing a second tag jump command get you the desired behavior? I m kind of out of ideas after that since different
          Message 4 of 11 , Oct 2, 2013
          • 0 Attachment
            On Wednesday, October 2, 2013 1:08:02 AM UTC-5, Henry wrote:
            > On Tuesday, October 1, 2013 5:18:59 PM UTC+2, Ben Fritz wrote:
            > > > > If that doesn't work, you could try modifying your MatchCaseTag function
            > > > > to issue a second tjump command in case the first doesn't work. It's a
            > > > > hack, but maybe it will fix your problem.
            > > > >
            > >
            > > I think instead of BuffAdd, I'd first try BufWinEnter. If that doesn't work,
            > > then maybe BufReadPost would work.
            >
            > Spent some time brushing up on events at
            > http://vimdoc.sourceforge.net/htmldoc/autocmd.html#{event}
            >
            > Sadly, "au BufWinEnter * nested tab sball" results in the error
            > "E435: Couldn't find tag, just guessing"
            >
            > And so does "au BufReadPost * nested tab sball"
            >
            > At times like this I wish I could slip into an alternate universe for a few weeks or months and study the problem to the exclusion of all else in as much depth as required until a solution is found, then return to "now" where my eyelids have yet to complete their last lubricating blink and be hailed an all-knowing demi god.
            >
            > oh well.

            Does the suggested workaround of issuing a second tag jump command get you the desired behavior? I'm kind of out of ideas after that since different autocmd events don't seem to avoid the problem.

            --
            --
            You received this message from the "vim_use" 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_use" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Henry Combrinck
            ... By in case the first doesn t work I presume you mean an exception? try exe tjump . expand( ) catch exe tjump . expand( ) finally
            Message 5 of 11 , Oct 2, 2013
            • 0 Attachment
              > > If that doesn't work, you could try modifying your MatchCaseTag function
              > > to issue a second tjump command in case the first doesn't work. It's a
              > > hack, but maybe it will fix your problem.

              By "in case the first doesn't work" I presume you mean an exception?

                  try
                      exe 'tjump ' . expand('<cword>')
                  catch
                      exe 'tjump ' . expand('<cword>')
                  finally
                     let &ic = ic
                  endtry


              But this doesn't do much because the first exe/tjump doesn't actually "fail" per se:  it always opens the file successfully...

              Unless I'm not understanding your suggestion correctly?



              On Wed, Oct 2, 2013 at 2:06 PM, Ben Fritz <fritzophrenic@...> wrote:
              On Wednesday, October 2, 2013 1:08:02 AM UTC-5, Henry wrote:
              > On Tuesday, October 1, 2013 5:18:59 PM UTC+2, Ben Fritz wrote:
              > > > > If that doesn't work, you could try modifying your MatchCaseTag function
              > > > > to issue a second tjump command in case the first doesn't work. It's a
              > > > > hack, but maybe it will fix your problem.
              > > > >
              > >
              > > I think instead of BuffAdd, I'd first try BufWinEnter. If that doesn't work,
              > > then maybe BufReadPost would work.
              >
              > Spent some time brushing up on events at
              > http://vimdoc.sourceforge.net/htmldoc/autocmd.html#{event}
              >
              > Sadly, "au BufWinEnter * nested tab sball" results in the error
              > "E435: Couldn't find tag, just guessing"
              >
              > And so does "au BufReadPost * nested tab sball"
              >
              > At times like this I wish I could slip into an alternate universe for a few weeks or months and study the problem to the exclusion of all else in as much depth as required until a solution is found, then return to "now" where my eyelids have yet to complete their last lubricating blink and be hailed an all-knowing demi god.
              >
              > oh well.

              Does the suggested workaround of issuing a second tag jump command get you the desired behavior? I'm kind of out of ideas after that since different autocmd events don't seem to avoid the problem.

              --
              --
              You received this message from the "vim_use" 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 a topic in the Google Groups "vim_use" group.
              To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/juMNxDig_O4/unsubscribe.
              To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.

              --
              --
              You received this message from the "vim_use" 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_use" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Ben Fritz
              ... Nope, I just meant something stupid and hacky like:     try         exe tjump . expand( )         exe tjump .
              Message 6 of 11 , Oct 2, 2013
              • 0 Attachment
                On Wednesday, October 2, 2013 7:37:35 AM UTC-5, Henry wrote:
                > > > If that doesn't work, you could try modifying your MatchCaseTag function
                >
                > > > to issue a second tjump command in case the first doesn't work. It's a
                >
                > > > hack, but maybe it will fix your problem.
                >
                > By "in case the first doesn't work" I presume you mean an exception?
                >
                >     try
                >         exe 'tjump ' . expand('<cword>')
                >
                >     catch
                >         exe 'tjump ' . expand('<cword>')
                >     finally
                >        let &ic = ic
                >     endtry
                >
                >
                > But this doesn't do much because the first exe/tjump doesn't actually "fail" per se:  it always opens the file successfully...
                >
                >
                > Unless I'm not understanding your suggestion correctly?
                >

                Nope, I just meant something stupid and hacky like:

                    try
                        exe 'tjump ' . expand('<cword>')
                        exe 'tjump ' . expand('<cword>')
                    finally
                       let &ic = ic
                    endtry

                Now I realize you could probably do better using the tag stack, taking a hint from the examples given just under ":help :tags":

                    try
                        exe 'tjump ' . expand('<cword>')
                        0tag
                    finally
                       let &ic = ic
                    endtry

                --
                --
                You received this message from the "vim_use" 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_use" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Henry Combrinck
                Thanks Ben, I actually did try exe tjump . expand( ) exe tjump . expand( ) initially, but all hell breaks lose with that :) Looks like
                Message 7 of 11 , Oct 3, 2013
                • 0 Attachment
                  Thanks Ben,

                  I actually did try

                           exe 'tjump ' . expand('<cword>')
                           exe 'tjump ' . expand('<cword>')

                  initially, but all hell breaks lose with that :)

                  Looks like

                     try
                           exe 'tjump ' . expand('<cword>')
                           0tag

                  Does the trick - at least in the sense that it *always* finds the relevant tag.  There's some weirdness with tab behaviour if you drill down, back out, then drill down again.  The second drill down results in new tabs never being opened again in the current session...  but screw it.  At least now it reliably finds the tag.

                  Thanks for your input!

                  Cheers
                  Henry
                    


                  On Wed, Oct 2, 2013 at 3:36 PM, Ben Fritz <fritzophrenic@...> wrote:
                  On Wednesday, October 2, 2013 7:37:35 AM UTC-5, Henry wrote:
                  > > > If that doesn't work, you could try modifying your MatchCaseTag function
                  >
                  > > > to issue a second tjump command in case the first doesn't work. It's a
                  >
                  > > > hack, but maybe it will fix your problem.
                  >
                  > By "in case the first doesn't work" I presume you mean an exception?
                  >
                  >     try
                  >         exe 'tjump ' . expand('<cword>')
                  >
                  >     catch
                  >         exe 'tjump ' . expand('<cword>')
                  >     finally
                  >        let &ic = ic
                  >     endtry
                  >
                  >
                  > But this doesn't do much because the first exe/tjump doesn't actually "fail" per se:  it always opens the file successfully...
                  >
                  >
                  > Unless I'm not understanding your suggestion correctly?
                  >

                  Nope, I just meant something stupid and hacky like:

                       try
                           exe 'tjump ' . expand('<cword>')
                           exe 'tjump ' . expand('<cword>')
                       finally
                          let &ic = ic
                       endtry

                  Now I realize you could probably do better using the tag stack, taking a hint from the examples given just under ":help :tags":

                       try
                           exe 'tjump ' . expand('<cword>')
                           0tag
                       finally
                          let &ic = ic
                       endtry

                  --
                  --
                  You received this message from the "vim_use" 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 a topic in the Google Groups "vim_use" group.
                  To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/juMNxDig_O4/unsubscribe.
                  To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.

                  --
                  --
                  You received this message from the "vim_use" 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_use" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Ben Fritz
                  ... Heh, I m actually realizing the first approach should not re-read the after the first tjump command, it should store off the expand( )
                  Message 8 of 11 , Oct 3, 2013
                  • 0 Attachment
                    On Thursday, October 3, 2013 4:29:11 AM UTC-5, Henry wrote:
                    > Thanks Ben,
                    >
                    > I actually did try
                    >
                    >          exe 'tjump ' . expand('<cword>')
                    >
                    >          exe 'tjump ' . expand('<cword>')
                    >
                    > initially, but all hell breaks lose with that :)
                    >
                    > Looks like
                    >
                    >    try
                    >
                    >          exe 'tjump ' . expand('<cword>')
                    >
                    >          0tag
                    >
                    > Does the trick - at least in the sense that it *always* finds the relevant tag. 

                    Heh, I'm actually realizing the first approach should not re-read the <cword> after the first tjump command, it should store off the expand('<cword>') result and use it twice instead of grabbing the word under the new cursor position.

                    But the second approach is nicer anyway, so I wouldn't bother trying to get the first to wok.

                    --
                    --
                    You received this message from the "vim_use" 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_use" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+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.