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

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

Expand Messages
  • Lech Lorens
    May 23, 2010
      On 20-May-2010 Robert Webb <stella4d@...> wrote:
      > Hey Lech,
      >
      > > > I noticed some problems myself now when using ^P and ^N in insert mode.
      > > > Sometimes if you break completion before it's found all results it seems to
      > > > cause problems. These commands don't need to disambiguate tags though, and
      > > > should really just use the default tags mechanism, not 'tagfunc'. Lech,
      > > > can you fix that?
      > >
      > > Strange. I'll try to look into it during the weekend. Meanwhile, maybe you
      > > could provide a detailed description of the steps needed to see what you
      > > mean? Your setting of 'cpt', 'tagfunc' (I assume it's the function you sent
      > > last time), etc. Perhaps you can use Vim source code to create a scenario in
      > > which you reproduce the problem?
      >
      > I was afraid you'd ask that. Yeah, I didn't look into it when it happened.
      > I'll try to take more notice next time. It was probably something to do with
      > me typing stuff while it was still filling in the list of matches.
      >
      > However, there's no reason to use 'tagfunc' for ^P/^N anyway. All we want
      > there is tag names, and no need to disambiguate tags of the same name, so
      > regardless, ^P/^N shouldn't use 'tagfunc'. Using tagfunc will also slow it
      > down since all tags files are looked at rather than one at a time.

      In another email I have already responded to this claim. I believe that
      'tagfunc' could improve the results during the completion and so its
      usage should not be disabled when completion is being done.

      > Another thing I noticed. If I tag to something that wasn't originally a tag
      > (eg a local variable), then it starts off working. Then :tn also works,
      > finding real tags. But :trew doesn't get back to the local var. That now
      > seems lost from the list of tags. In fact, shouldn't :tselect show my local
      > var tag first? I don't see it. I think it loses it when it goes to the next
      > tags file in 'tags', but it shouldn't be doing that because my script already
      > looked at all tags, as returned by taglist() which looks at all files in
      > 'tags'.

      I've had a quick look at this one and I think I understand the cause.
      Currently the tagging mechanism works in such a way that if e.g. :tnext
      is executed, a list of tags is fetched anew and current-index-+1-th tag
      is used for a jump. The index of the new tag is remembered. This means
      that:
      - the list of tags is expected not to change between selecting a tag for
      the first time (e.g. with ^]) and executing :tnext, :trew, :tlast etc,
      - 'tagfunc' is re-evaluated for each of the commands which are related
      to tag management. However, only ^] causes 'tagfunc' to be called with
      the 'c' flag specified, so the results returned by 'tagfunc' can
      differ.

      Fixing this will require the tagging mechanism in Vim to be modified and
      your script to return a full list of tags at each call (currently if
      a local variable is found, the returned list does not include any more
      tags).

      I will have a look at the first part of the task (i.e. Vim modification)
      ASAP. Unfortunately, ASAP is unlikely to mean soon.

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