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

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

Expand Messages
  • Robert Webb
    ... Oh, sorry, yes leave that to the user s script. ... OK. Maybe down the road it could be an extra flag for taglist(). We seem to have a few potential flags
    Message 1 of 25 , May 3, 2010
    • 0 Attachment
      Lech Lorens wrote:

      > What I meant is: if the user's function used in 'tagfunc' returns a
      > 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
      > returned.

      Oh, sorry, yes leave that to the user's script.

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

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

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

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

      Thanks,
      Rob.

      --

      Robert Webb <Stella4D@...>,
      Software developer
      http://www.software3d.com

      --
      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
    • Lech Lorens
      ... 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
      Message 2 of 25 , 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
      • Robert Webb
        ... That s right. But what do you think of my tagcmdfunc idea? That would allow my script to handle multiple successive searches, as well as multiple
        Message 3 of 25 , May 7, 2010
        • 0 Attachment
          Lech Lorens wrote:

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

          That's right. But what do you think of my 'tagcmdfunc' idea?
          That would allow my script to handle multiple successive searches, as
          well as multiple guesses when a search fails. There'd be no need for
          the multiple search feature in vim then. It would be left to the
          script. So 'tagfunc' could put whatever it wants in the tag command,
          and 'tagcmdfunc' would know what to do with it. Seems the most
          flexible solution. Although hmm, if taglist() is called by another
          script it may get something unexpected. Maybe taglist() shouldn't use
          'tagfunc' by default?

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

          Ah! For the life of me I couldn't remember or find how to do that.
          I kept looking for :doctags! Thanks. Actually I looked at the doc
          for "write-plugin" expecting to find it there, but no mention of it.
          Would be a good thing to mention for people writing plugins, no?

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

          Hmm, I guess, but this will have many other ramifications. The point
          is that the 'tagfunc' handles things its own way, such as finding
          valid C++ operators like mine does. Neither vim not the user need
          know how it's done, so they shouldn't need a special isk setting.

          I think when 'tagfunc' is set, vim should call it even when it doesn't
          think there's an identifier under the cursor. It is up to the script
          to find what it wants. Which leads into...

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

          If vim called 'tagfunc' regardless of what is found under the cursor,
          as I'm suggesting, then it becomes 'tagfunc's responsibility to say
          whether it found an identifier under the cursor. So I'm suggesting
          that if it returns 0 it means no id was found, and vim then knows to
          give the "E349: No identifier under cursor" error. If however it
          returns an empty list, then it means an id was found, but no tags.
          In this case vim knows to give the "E426: tag not found" error.

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

          Well, I wonder that too, and it's possible. It's just that I reported
          that other bug referenced above (a year or so ago) which was very
          similar, and... bah, you know what, I just tried it again and now I
          can't get it to happen! It happens using my old mappings (before
          'tagfunc') but isn't happening when using vim's tag commands. Forget
          it for now, I'll keep an eye out for it.

          Rob.

          --

          Robert Webb <Stella4D@...>,
          Want to make polyhedra?
          http://www.software3d.com/Stella.php

          --
          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
        • Robert Webb
          Attached is a new version of my SmartTag script, which attempts to improve C/C++ tagging in a few ways: - Try to resolve ambiguous tags - Tag to operators -
          Message 4 of 25 , May 11, 2010
          • 0 Attachment
            Attached is a new version of my SmartTag script, which attempts to improve
            C/C++ tagging in a few ways:

            - Try to resolve ambiguous tags
            - Tag to operators
            - Tag with cursor on "delete" to jump to destructor
            - Tag to local variables (not defined in tags file)
            - NEW: Tag to labels from goto statements

            Can integrate with vim's tag mechanism using Lech Loren's 'tagfunc' patch.

            New version has some bug fixes and the new tagging on goto statements.

            Test files in attached ZIP have also been updated.

            Thanks,
            Rob.

            --

            Robert Webb <Stella4D@...>,
            Software developer
            http://www.software3d.com

            --
            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
          • marco-oweber
            I couldn t resist: I used github because it works best and fastest for me: http://github.com/MarcWeber/SmartTag I also moved code and renamed SmartTag to
            Message 5 of 25 , May 18, 2010
            • 0 Attachment
              I couldn't resist:

              I used github because it works best and fastest for me:

              http://github.com/MarcWeber/SmartTag

              I also moved code and renamed SmartTag to SmartTag#SmartTag

              When enabling tagfunc by setting to SmartTag or SmartTag#SmartTag should
              tjump show only one match as well? This didn't work for me.

              The :call SmartTag#SmartTag('goto')

              Does not require that feature, does it?

              Robert: Do you have a www.vim.org account?
              You can use the SVN mirror and use svn diff to create diffs
              which youc an send to me. You can also install git.
              I could create a SSH account which you can login into to push
              changes yourself.

              Lech: Do you have a repository location now?

              Marc Weber

              --
              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
            • Robert Webb
              ... What does the # do? Is that like a namespace or something? ... Hmm, I never use tjump. My script does not try to return just one tag. Rather it tries to
              Message 6 of 25 , May 19, 2010
              • 0 Attachment
                Marc Weber wrote:

                > I couldn't resist:
                >
                > I used github because it works best and fastest for me:
                >
                > http://github.com/MarcWeber/SmartTag
                >
                > I also moved code and renamed SmartTag to SmartTag#SmartTag

                What does the # do? Is that like a namespace or something?

                > When enabling tagfunc by setting to SmartTag or SmartTag#SmartTag should
                > tjump show only one match as well? This didn't work for me.

                Hmm, I never use tjump. My script does not try to return just one tag.
                Rather it tries to put the tags in a better order. Even if it thinks it knows
                which one's best, it could always be wrong, so tags are reordered, but still
                kept for use with :tn etc. Something different would be required if we want
                :tjump to know when my script is pretty sure there's only one sensible tag.

                Actually, if you always want it to throw away tags that it doesn't think are
                right, try changing 'nk' to 'n' in the SmartTagFunc() function ('k' means to
                "keep" all tags, but put the best ones first). But I don't think that should
                be the default behaviour, as it is not as useful with :tn etc.

                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?

                > Robert: Do you have a www.vim.org account?

                Nope.

                > You can use the SVN mirror and use svn diff to create diffs
                > which youc an send to me. You can also install git.
                > I could create a SSH account which you can login into to push
                > changes yourself.

                I'll have to look into this another time. Is it not possible to submit changes
                via a web interface? That is, without installing git?

                I'm only making very minor changes occasionally when I encounter problems. For
                now I'll just send you any new versions. I'll send you one after this.

                Thanks,
                Rob.

                --

                Robert Webb <Stella4D@...>,
                Software developer
                http://www.software3d.com

                --
                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
              • Lech Lorens
                ... Not quite. The part before the # is used to denote the autoload script in which a given function is defined. Autoload scripts are lazily sourced - only
                Message 7 of 25 , May 19, 2010
                • 0 Attachment
                  On 19-May-2010 Robert Webb <stella4d@...> wrote:
                  > > I also moved code and renamed SmartTag to SmartTag#SmartTag
                  >
                  > What does the # do? Is that like a namespace or something?

                  Not quite. The part before the # is used to denote the autoload script
                  in which a given function is defined. Autoload scripts are lazily
                  sourced - only when a given function is called.
                  ":help autoload" provides some more details.

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

                  --
                  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
                • Robert Webb
                  Hey Lech, ... 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
                  Message 8 of 25 , May 20, 2010
                  • 0 Attachment
                    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.

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

                    Rob.

                    --

                    Robert Webb <Stella4D@...>,
                    Software developer
                    http://www.software3d.com

                    --
                    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
                  • Lech Lorens
                    ... 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
                    Message 9 of 25 , May 23, 2010
                    • 0 Attachment
                      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
                    • Robert Webb
                      ... Good point. I guess it could act like a kind of intellisense, like only completing names of valid members of classes etc. A different flag should be
                      Message 10 of 25 , May 24, 2010
                      • 0 Attachment
                        Lech Lorens wrote:

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

                        Good point. I guess it could act like a kind of intellisense, like only
                        completing names of valid members of classes etc. A different flag
                        should be passed to 'tagfunc' then when insert-mode completion is
                        expected. Scripts not wanting to deal with it can just call taglist().

                        Actually I didn't check to see whether the 'c' flag (for context) was
                        passed for ^P/^N. But I presumed it was, which was causing the
                        problems. We should add the 'i' flag maybe for insert mode. Then my
                        script will be able to tell the difference.

                        Currently it will still require searching all files in 'tags' however.

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

                        Really? But even vim's normal tagging gets tags in a different order
                        depending on what file you're in. Eg it will find tags in the current
                        file before others. Wouldn't that be a problem if the tag list was
                        re-created for every :tn?

                        > Fixing this will require ... 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).

                        Actually, even just changing this in the script would probably fix it.
                        I suspect it must be keeping the list of tags between :tn etc, but
                        updates the list when reaching the end and fetching the next entry in
                        'tags'.

                        I figured if it was a local variable, then I could save the time spent
                        getting tags, but meh, maybe it should just do it anyway.

                        Thanks,
                        Rob.

                        --

                        Robert Webb <Stella4D@...>,
                        Want to make polyhedra?
                        http://www.software3d.com/Stella.php

                        --
                        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
                      • Robert Webb
                        ... You forgot to add SmartTag# to the SmartTagFunc() function for use with tagfunc , to the test script, and in the docs. I ve done that and made a few
                        Message 11 of 25 , May 24, 2010
                        • 0 Attachment
                          Marc Weber wrote:

                          > I couldn't resist:
                          >
                          > I used github because it works best and fastest for me:
                          >
                          > http://github.com/MarcWeber/SmartTag
                          >
                          > I also moved code and renamed SmartTag to SmartTag#SmartTag

                          You forgot to add SmartTag# to the SmartTagFunc() function for use with 'tagfunc', to the test script, and in the docs. I've done that and made a few other changes. I put some of the doc file back in the script as it was more implementation details, and included a brief summary of what the script's for in both places. Also fixed a bug or two and added relevant tests to the test script.

                          Can you put this into git?

                          Thanks,
                          Rob.

                          --

                          Robert Webb <Stella4D@...>,
                          Software developer
                          http://www.software3d.com

                          --
                          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
                        Your message has been successfully submitted and would be delivered to recipients shortly.