56657RE: New script: SmartTag (resolves ambiguous C++ tags etc)
- May 3, 2010Lech Lorens wrote:
> What I meant is: if the user's function used in 'tagfunc' returns aOh, sorry, yes leave that to the user's script.
> list of tags, should I verify that there are no duplicates in the
> list? I'd say: no - leave it to the user to take care of what is
> Another issue is whether taglist() should remove duplicates. ItOK. Maybe down the road it could be an extra flag for taglist().
> might be good to handle this but for now I'd rather stick to
> 'tagfunc' to get it done well.
We seem to have a few potential flags required now for taglist().
'u' for unique tags? This would not get rid of tags of the same name,
only those that have the same name, cmd & file. It would save my
script having to do it, which it does pretty inefficiently.
> > - Another thing I need is a way to do more than one search in theOK. I was hoping the first of those wouldn't be too hard at least.
> > tag command.
> > - Gets a little trickier than above too, because I want to have
> > access to all of vim's search capabilities in that tag command.
> > The format of a search
> > - Vim doesn't load all tags when it does a tag search. It looks
> > at one file
> It would be great to have all of them, but I consider them
> improvements to the basic functionality offered by 'tagfunc'. Once
> 'tagfunc' is implemented properly these can be considered.
Currently my test script will fail without it. I find often there's
tags of the same name with the same search commend within a header
file, ie the same line appears twice, within different classes.
Currently my script also makes a second guess if the search fails,
which complicates things further. One solution might be to add
another option, say 'tagcmdfunc', which calls back a user-function to
do the search. It would mean though that I could do multiple searches
as required to find the right line, and if they fail, I can make as
many subsequent guesses as I want (for when the tags file is a little
out of date). It also means that vim's built-in handling of tag
commands doesn't have to be modified. Probably leave it to vim to
open the tag file, then just pass the tag command to the
user-function. What do you think?
> Some news about 'tagfunc': I discovered that the 'tagfunc'If it only looks at those entries, why does it matter if other entries
> implementation prevented omni completion for C from working when
> 'tagfunc' was set to the SmartTagFunc() function defined a few lines
> above. This was due to the fact that - as mentioned by the
> documentation - in each of the dictionaries returned by
> SmartTagFunc() only the entries 'name', 'filename' and 'cmd' are
> considered relevant. Without thinking too much I simply discarded
> all the other entries effectively filtering out the data essential
> to omni completion. The latest patch fixes the problem. Find it
are present? Are you sure it wasn't your other minor change to my
SmartTagFunc() function that fixed it? That would make more sense,
that it expects taglist() to find matches for partial tag patterns.
I'm thinking there might be some use in keeping those fields, eg the
'tagcmdfunc' idea above might have use for them.
> And by the way... 'tagfunc' is now available via vim_extended onThanks, and I've compiled it now, at work since it wasn't working at
By the way, I notice that docs/tags hasn't been updated in that
version (doesn't have a tags for 'tagfunc' etc).
- I attach a new version:
- Includes the SmartTagFunc() function. Users need to put
"set tagfunc=SmartTagFunc" in their .vimrc or _vimrc.
- Fixes (hopefully) the errors you got initially
- Fixes errors which occur in my test script when 'tagfunc' is set
(by unsetting it temporarily). Those errors occurred because my
script calls my functions directly rather than via 'tagfunc', so
any calls to taglist() would recursively call back my script a
second time. Maybe taglist() needs a flag telling it not to use
- My new SmartTagFunc() allows the user to do ":tag Class::Member"
to explicitly find a tag from a specific class.
Some other observations re 'tagfunc':
- Can't tag on operator at end of line, eg "b++;". Needs to allow
this when 'tagfunc' set. However if the tagfunc returns an empty
list, how do we know if an id wasn't found, or if no tags for it
were found (so vim knows which error to give)? Maybe return an
empty list for tag-not-found or 0 for id-not-found?
- ^W^] then ^Wq leaves the original window scrolled sometimes. Not
sure when exactly. But try this: extract the attached ZIP file and
open TestTags.cpp. Go to line 332 and use ^E/^Y to put it in the
bottom half of the screen, towards the bottom. Tag to one of the
first 4 taggable items (ie b, mNext, mPrev or mA) using ^W], then
close that window again with ^Wq. The original cursor line is now
at the top of the window. Strangely it doesn't happen for the
remaining tags on the line. I think I also saw it only happen when
the tag was in the top half of the window. Probably the same bug as
Actually I just tried minimal tagfunc, and it doesn't seem to do
it, so it could be a fault with my script, although the link above
shows that there's something wrong. Here's the minimal tagfunc I
function! MyTagFunc(pattern, flags)
Robert Webb <Stella4D@...>,
You received this message from the "vim_dev" 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
- << Previous post in topic Next post in topic >>