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

56686Re: New script: SmartTag (resolves ambiguous C++ tags etc)

Expand Messages
  • Lech Lorens
    May 6, 2010
    • 0 Attachment
      On 03-May-2010 Robert Webb <stella4d@...> wrote:
      > Lech Lorens wrote:
      > > Another issue is whether taglist() should remove duplicates. It
      > > might be good to handle this but for now I'd rather stick to
      > > 'tagfunc' to get it done well.
      >
      > OK. Maybe down the road it could be an extra flag for taglist().
      > 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 the
      > > > 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.
      >
      > OK. I was hoping the first of those wouldn't be too hard at least.
      > 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?

      I looked into the things I thought to be problems in the 'tagfunc'
      implementation and found out that I misinterpreted the results I was
      getting. In other words: 'tagfunc' has been stable for me and I'll try
      to find some time during the weekend to look into the other things you'd
      like to be done. To be 100% sure: you think that it would be best to get
      multiple searches done first (or do you mean removing duplicate tags)?

      > > Some news about 'tagfunc': I discovered that the 'tagfunc'
      > > 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
      > > attached.
      >
      > If it only looks at those entries, why does it matter if other entries
      > 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.

      Yes, I am sure. I didn't it clear that it's the :tag command that only
      looks at those three entries. The completion script uses taglist() to
      get tags and expects to get more than just these three.

      > > And by the way... 'tagfunc' is now available via vim_extended on
      > > repo.or.cz:
      > > http://repo.or.cz/w/vim_extended.git/shortlog/refs/heads/feat/tagfunc
      >
      > Thanks, and I've compiled it now, at work since it wasn't working at
      > home.
      >
      > By the way, I notice that docs/tags hasn't been updated in that
      > version (doesn't have a tags for 'tagfunc' etc).

      Thanks for noticing. Will fix that. Meanwhile:
      :helptags $VIMRUNTIME/doc

      > - 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
      > 'tagfunc'?
      > - 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.

      You can tag an operator. You will want to set 'isk' appropriately.
      Probably:
      :set isk+=-+

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

      There is "E426: tag not found". Id not found?
      If you mean "E349: No identifier under cursor", Vim takes care of this,
      no need to do this in the 'tagfunc' function.

      > - ^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
      > here: http://tech.groups.yahoo.com/group/vimdev/message/51805
      >
      > 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
      > used:
      >
      > function! MyTagFunc(pattern, flags)
      > return taglist(a:pattern)
      > endfunc
      > set tagfunc=MyTagFunc

      I haven't looked into it yet, but I was thinking whether this could be
      related to the fact that you change the position of the cursor while
      preparing a tag list.

      --
      Cheers,
      Lech

      --
      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
    • Show all 25 messages in this topic