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

Each buffer in own tab/function lookup seem to clash

Expand Messages
  • Henry Combrinck
    Greets, I ve tried this on vim 7.3 and 7.4. The problem: if I enable au BufAdd,BufNewFile... , then C-] often jumps to the incorrect position in the file
    Message 1 of 11 , Sep 30, 2013
      Greets,

      I've tried this on vim 7.3 and 7.4.

      The problem:  if I enable "au BufAdd,BufNewFile...", then C-] often jumps to the incorrect position in the file containing a function/subroutine declaration.  This happens whether I use the call to MatchCaseTag() or not.

      If I disable "au BufAdd,BufNewFile...", then it always jumps to the correct position - without fail.  But having vim remember my cursor position per file is indispensable.

      My .vimrc contains:

      set ai
      set tabstop=4
      set shiftwidth=4
      syntax on
      set expandtab
      set smarttab
      set smartindent
      set backspace=indent,eol,start
      set tags+=tags;~

      " don't format/autoindent pasted text
      nnoremap <F2> :set invpaste paste?<CR>
      set pastetoggle=<F2>
      set showmode

      " remember last cursor position
      if has("autocmd")
        au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
      endif

      " toggle last search term highlighting
      "map  <F12> :set hls!<CR>
      "imap <F12> <ESC>:set hls!<CR>a
      "vmap <F12> <ESC>:set hls!<CR>gv
      map  <C-h> :set hls!<CR>
      imap <C-h> <ESC>:set hls!<CR>a
      vmap <C-h> <ESC>:set hls!<CR>gv

      " uppercase current word
      map <C-u> gUiw
      " lowercase current word
      map <C-l> guiw

      " switch off last found highlight
      map ; /adfadf<CR><C-g>

      map <C-]> :call MatchCaseTag()<CR>
      " following is so g] works on class::method
      set iskeyword+=:
      nmap <C-Enter> <C-w><C-]><C-w>T


      set hlsearch
      highlight MatchParen ctermbg=yellow guibg=yellow

      set showtabline=2               " File tabs allways visible
      " c-pageup/down switches tabs
      " :tabnew etc

      " each buffer in it's own tab.
      au BufAdd,BufNewFile * nested tab sball

      "set nocompatible
      map OA k
      map <Down> j
      map <Left> h
      map <Right> l

      fun! MatchCaseTag()
          let ic = &ic
          set noic
          try
              exe 'tjump ' . expand('<cword>')
          finally
             let &ic = ic
          endtry
      endfun

      " auto-add comments
      set formatoptions+=r

      " check with :make
      autocmd FileType perl set makeprg=perl\ -c\ %\ $*
      autocmd FileType perl set errorformat=%f:%l:%m
      autocmd FileType perl set autowrite

      " Tidy selected lines (or entire file) with _t:
      " (perltidy does not exist on eros)
      nnoremap <silent> _t :%!perltidy -q<Enter>
      vnoremap <silent> _t :!perltidy -q<Enter>

      " my perl includes pod
      let perl_include_pod = 1
      " syntax color complex things like @{${"foo"}}
      let perl_extended_vars = 1

      ---

      I'd appreciate any pointers on what I'm doing incorrectly.

      Thanks
      Henry

      --
      --
      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
      ... OK, but why are you mentioning the remembered cursor position? If I understand your .vimrc (below) correctly, that s a completely separate autocmd that (so
      Message 2 of 11 , Sep 30, 2013
        On Monday, September 30, 2013 9:01:17 AM UTC-5, Henry Combrinck wrote:
        >
        >
        > The problem:  if I enable "au BufAdd,BufNewFile...", then C-] often
        > jumps to the incorrect position in the file containing a
        > function/subroutine declaration.  This happens whether I use the call
        > to MatchCaseTag() or not.
        >
        >
        > If I disable "au BufAdd,BufNewFile...", then it always jumps to the
        > correct position - without fail.  But having vim remember my cursor
        > position per file is indispensable.
        >

        OK, but why are you mentioning the remembered cursor position? If I
        understand your .vimrc (below) correctly, that's a completely separate
        autocmd that (so far) hasn't entered into your description.

        But maybe it's one culprit.

        > My .vimrc contains:
        >
        > [snip]
        >
        > " remember last cursor position
        > if has("autocmd")
        >   au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
        > endif
        >
        > [snip]
        >
        > map <C-]> :call MatchCaseTag()<CR>
        > " following is so g] works on class::method
        > set iskeyword+=:
        >
        > nmap <C-Enter> <C-w><C-]><C-w>T

        Side note: Is this last mapping necessary? You have an autocmd to
        already force a new buffer into a new tab. What's this one for? Opening
        a new tab for existing buffers?

        > [snip]
        >
        > " each buffer in it's own tab.
        > au BufAdd,BufNewFile * nested tab sball
        >
        > "set nocompatible
        > map OA k
        > map <Down> j
        > map <Left> h
        > map <Right> l
        >

        Side note: By default Vim already moves around in every mode when you
        use the arrow keys, I don't think these mappings are needed.

        >
        > fun! MatchCaseTag()
        >     let ic = &ic
        >     set noic
        >     try
        >         exe 'tjump ' . expand('<cword>')
        >     finally
        >        let &ic = ic
        >     endtry
        > endfun
        >
        > " auto-add comments
        >
        >
        > I'd appreciate any pointers on what I'm doing incorrectly.
        >

        Your first problem is trying to force one-buffer-per-tab in all
        situations. That's always a recipe for headaches. But with that "maybe
        you should reconsider" note, I'll try to work with you here.

        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.

        --
        --
        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 for the detailed response Ben - ... You can ignore this one - it was an experiment which I forgot to remove before posting my query. ... This was me
        Message 3 of 11 , Sep 30, 2013
          Thanks for the detailed response Ben -

          On Monday, September 30, 2013 5:01:54 PM UTC+2, Ben Fritz wrote:
          > > nmap <C-Enter> <C-w><C-]><C-w>T
          >
          >
          >
          > Side note: Is this last mapping necessary? You have an autocmd to
          >
          > already force a new buffer into a new tab. What's this one for? Opening
          >
          > a new tab for existing buffers?

          You can ignore this one - it was an experiment which I forgot to remove before posting my query.


          > > map OA k
          >
          > > map <Down> j
          >
          > > map <Left> h
          >
          > > map <Right> l
          >
          >
          >
          > Side note: By default Vim already moves around in every mode when you
          >
          > use the arrow keys, I don't think these mappings are needed.

          This was me trying to get terminals to work correctly on an older Solaris machine which had old crappy terminfos - I eventually got it to work, so left this as-is.


          > Your first problem is trying to force one-buffer-per-tab in all
          >
          > situations. That's always a recipe for headaches. But with that "maybe
          >
          > you should reconsider" note, I'll try to work with you here.

          I hear you - It would be nice to perhaps get a new buffer only when I hit C-].


          > 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.

          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).

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

          I'll continue scratching around, but any suggestions are welcome.

          Regards
          Henry

          --
          --
          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
          ... 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 4 of 11 , Oct 1, 2013
            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 5 of 11 , Oct 1, 2013
              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 6 of 11 , Oct 2, 2013
                -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 7 of 11 , Oct 2, 2013
                  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 8 of 11 , Oct 2, 2013
                    > > 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 9 of 11 , Oct 2, 2013
                      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 10 of 11 , Oct 3, 2013
                        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 11 of 11 , Oct 3, 2013
                          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.