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

-original message-
Subject: Re: Each buffer in own tab/function lookup seem to clash
From: Henry Combrinck <henrylcombrinck@gmail.com>
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@googlegroups.com.
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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.