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

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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.