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

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