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

vim6: (todo?) regexp & tags

Expand Messages
  • Zdenek Sekera
    I browsed the vim6 TODO for the following two items, couldn t find any reference to them, hence two questions: 1. Regexp: some time ago I asked if vim has a
    Message 1 of 11 , Nov 7, 2000
      I browsed the vim6 TODO for the following two items, couldn't
      find any reference to them, hence two questions:

      1. Regexp: some time ago I asked if vim has a nice regexp to resolve
      the following:
      \<endwhile\|endwhil\|endwhi\|endwh\|endw\>
      in a more compact (faster? processing) way (this is very
      useful when parsing keywords allowed to have a minimum number of
      chars).
      There were two suggestions, but Bram mentioned:

      Bram says:
      > I don't think there is a nice solution. Perhaps regexp need to be
      extended
      > for this? I wonder if other regexp patterns have a special code
      for this.
      > Something like "endw\{hile\}".

      That looked to me as a very nice solution. Is that planned for vim6?

      2. Tags: I am using tags all day every day, most often on a huge source
      base.
      Often I don't really know which of the matching tags displayed
      (sometime around 100), is the one I want, so I have to try a few.
      Given this, I see the following problems with tags today:
      - when I choose a tag, the display of matching tags disappears.
      I know I can get *next* or *previous* but that's not practical
      when
      going from 5th to 37th. I have to invoke <C-]> again to go
      through
      the whole tag-searching process again.
      So I'd like an option that keeps that display for me and I can
      have
      it go away when I want to.
      - often I need to look at several files to compare and see what I want,
      or I'd like to keep those several .h files (found by tags)
      around for
      longer time.
      I'd like to have a possibility to fire off my own window(s) or
      whatever
      (I understand I would use the <C-T> to go back but that's
      fine) for
      those files.
      All in all, what I am asking is to get somehow access to the tag so I
      could
      do with it what I want, somehow *intercept* the process: when tag is
      chosen
      from matching tags vim should give it to me (by some option,
      whatever) and *not*
      automatically display it *instead* of my current file (i want to keep
      that
      one in the window all the time).

      When I asked *something like* this some time ago, Bram mentioned
      having in mind
      some sort of generic tag(??) browser that would allow this (and keep
      the old
      behaviour as well) but I can't find much about that in my archives.

      Anyway, somebody might remember, if not take this as a new question.
      Could anything like this be expected in vim6?

      Thanks.

      ---Zdenek
    • Bram Moolenaar
      ... I didn t get a response about how other regexp parsers do this. Doesn t Perl have something for this? I agree that it s a useful addition. But not with
      Message 2 of 11 , Nov 7, 2000
        Zdenek Sekera wrote:

        > I browsed the vim6 TODO for the following two items, couldn't
        > find any reference to them, hence two questions:
        >
        > 1. Regexp: some time ago I asked if vim has a nice regexp to resolve
        > the following:
        > \<endwhile\|endwhil\|endwhi\|endwh\|endw\>
        > in a more compact (faster? processing) way (this is very
        > useful when parsing keywords allowed to have a minimum number of chars).
        > There were two suggestions, but Bram mentioned:
        >
        > Bram says:
        > > I don't think there is a nice solution. Perhaps regexp need to be
        > > extended for this? I wonder if other regexp patterns have a special
        > > code for this. Something like "endw\{hile\}".
        >
        > That looked to me as a very nice solution. Is that planned for vim6?

        I didn't get a response about how other regexp parsers do this. Doesn't Perl
        have something for this?

        I agree that it's a useful addition. But not with highest priority.

        Note that "endw\{hile\}" isn't possible, because \{ already has a meaning. It
        could be something like "endw\@[hile\]". The [] construction is often used
        for optional parts.

        > 2. Tags: I am using tags all day every day, most often on a huge source
        > base.
        > Often I don't really know which of the matching tags displayed
        > (sometime around 100), is the one I want, so I have to try a few.
        > Given this, I see the following problems with tags today:

        If you have 100 matching tags, you have a problem already. I would start by
        finding a way to reduce the number of matches.

        > - when I choose a tag, the display of matching tags disappears.
        > I know I can get *next* or *previous* but that's not practical
        > when going from 5th to 37th. I have to invoke <C-]> again to go
        > through the whole tag-searching process again.
        > So I'd like an option that keeps that display for me and I can
        > have it go away when I want to.

        Why not use ":tselect"?

        > - often I need to look at several files to compare and see what I want,
        > or I'd like to keep those several .h files (found by tags) around
        > for longer time. I'd like to have a possibility to fire off my
        > own window(s) or whatever (I understand I would use the <C-T> to
        > go back but that's fine) for those files.

        I don't understand this one. You can split off windows to keep the files
        visible, or put file marks in them to be able to quickly jump to them again.

        > All in all, what I am asking is to get somehow access to the tag so I
        > could do with it what I want, somehow *intercept* the process: when tag
        > is chosen from matching tags vim should give it to me (by some option,
        > whatever) and *not* automatically display it *instead* of my current file
        > (i want to keep that one in the window all the time).

        This is too vague. "give you the tag"? You should be able to do most things
        by splitting the window and jumping to the tag in that one. Then you have the
        new position and can do whatever you want to do next.

        > When I asked *something like* this some time ago, Bram mentioned having
        > in mind some sort of generic tag(??) browser that would allow this (and
        > keep the old behaviour as well) but I can't find much about that in my
        > archives.

        It's a generic idea of having a window where you can select items from a list.
        The quickfix window is like that. For tags we would have to generate an error
        list from the tag matches.

        > Anyway, somebody might remember, if not take this as a new question.
        > Could anything like this be expected in vim6?

        Not much. I'm starting to cut down on adding new features and first finish
        the things that are half-finished. I want to get 6.0 ready for release.

        --
        "Oh, no! NOT the Spanish Inquisition!"
        "NOBODY expects the Spanish Inquisition!!!"
        -- Monty Python sketch --
        "Oh, no! NOT another option!"
        "EVERYBODY expects another option!!!"
        -- Discussion in vim-dev mailing list --

        /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
        \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
      • raf
        ... how about: slightly shorter and probably(?) faster than the method above. it would be faster still if vim has the
        Message 3 of 11 , Nov 7, 2000
          Bram Moolenaar wrote:

          > Zdenek Sekera wrote:
          >
          > > I browsed the vim6 TODO for the following two items, couldn't
          > > find any reference to them, hence two questions:
          > >
          > > 1. Regexp: some time ago I asked if vim has a nice regexp to resolve
          > > the following:
          > > \<endwhile\|endwhil\|endwhi\|endwh\|endw\>
          > > in a more compact (faster? processing) way (this is very
          > > useful when parsing keywords allowed to have a minimum number of chars).

          how about: \<endw\(h\(i\(l\(e\)\=\)\=\)\=\)\=\>
          slightly shorter and probably(?) faster than the method above.
          it would be faster still if vim has the equivalent of perl's
          (?:) non-backreferencing grouping operators. does it?

          > > There were two suggestions, but Bram mentioned:
          > >
          > > Bram says:
          > > > I don't think there is a nice solution. Perhaps regexp need to be
          > > > extended for this? I wonder if other regexp patterns have a special
          > > > code for this. Something like "endw\{hile\}".
          > >
          > > That looked to me as a very nice solution. Is that planned for vim6?
          >
          > I didn't get a response about how other regexp parsers do this. Doesn't Perl
          > have something for this?

          don't think so.

          raf
        • Matthew Winn
          ... I don t think it does. If it did then this would be (comparatively) easy to implement as a preprocessing stage of regexp compilation: just copy and
          Message 4 of 11 , Nov 7, 2000
            On Tue, Nov 07, 2000 at 10:27:48PM +1100, raf wrote:
            > Bram Moolenaar wrote:
            >
            > > Zdenek Sekera wrote:
            > >
            > > > I browsed the vim6 TODO for the following two items, couldn't
            > > > find any reference to them, hence two questions:
            > > >
            > > > 1. Regexp: some time ago I asked if vim has a nice regexp to resolve
            > > > the following:
            > > > \<endwhile\|endwhil\|endwhi\|endwh\|endw\>
            > > > in a more compact (faster? processing) way (this is very
            > > > useful when parsing keywords allowed to have a minimum number of chars).
            >
            > how about: \<endw\(h\(i\(l\(e\)\=\)\=\)\=\)\=\>
            > slightly shorter and probably(?) faster than the method above.
            > it would be faster still if vim has the equivalent of perl's
            > (?:) non-backreferencing grouping operators. does it?

            I don't think it does. If it did then this would be (comparatively)
            easy to implement as a preprocessing stage of regexp compilation: just
            copy and rewrite the regexp and then hand it over to the original
            routine. Without an equivalent of Perl's (?:...) construction all
            the backreference counts would have to be adjusted and it gets ugly
            rather quickly.

            Note that the lack of non-capturing parentheses won't slow it down
            _much_: the first set of parentheses won't be entered unless something
            matching /\<endw/ is found first, which isn't going to happen often.

            > > I didn't get a response about how other regexp parsers do this. Doesn't Perl
            > > have something for this?
            >
            > don't think so.

            No, it doesn't. In Perl it would be /\bendw(?:h(?:i(?:le?)?)?)?\b/
            which is more readable than the Vim version, but only just.

            --
            Matthew Winn (matthew@...)
          • Zdenek Sekera
            ... This very same suggestion (later even a bit simplified) came at that time from Matthew Winn who also gave a measurement on a (very?) long file: 10x faster!
            Message 5 of 11 , Nov 7, 2000
              raf wrote:
              >
              > Bram Moolenaar wrote:
              >
              > > Zdenek Sekera wrote:
              > >
              > > > I browsed the vim6 TODO for the following two items, couldn't
              > > > find any reference to them, hence two questions:
              > > >
              > > > 1. Regexp: some time ago I asked if vim has a nice regexp to resolve
              > > > the following:
              > > > \<endwhile\|endwhil\|endwhi\|endwh\|endw\>
              > > > in a more compact (faster? processing) way (this is very
              > > > useful when parsing keywords allowed to have a minimum number of chars).
              >
              > how about: \<endw\(h\(i\(l\(e\)\=\)\=\)\=\)\=\>
              > slightly shorter and probably(?) faster than the method above.

              This very same suggestion (later even a bit simplified) came at that
              time from
              Matthew Winn who also gave a measurement on a (very?) long file: 10x
              faster!

              Here is the snippet of the mail exchange *from those times*:

              Zdenek Sekera says:
              > Mathew Winn says:
              >> Very nice, though still not very readable due to the syntax.

              > It didn't need to be quite that unreadable: I got overenthusiastic
              > with the parentheses. \<endw\(h\(i\(le\=\)\=\)\=\)\=\> should be
              > just as good, for a suitably unreadable value of "good". It's fast,
              > though: 2 seconds to find "endwhile" at the end of /usr/dict/words
              > in comparison with 22 seconds for the version using \|.

              Not bad....!


              Bram says:
              > I didn't get a response about how other regexp parsers do this. Doesn't Perl
              > have something for this?

              Not that I know of, actully I don't know of any language that has that.

              > I agree that it's a useful addition. But not with highest priority.

              Agreed. It could be considered when there is an activity in the regexp
              area.

              ---Zdenek
            • Zdenek Sekera
              ... This is too simplistic view, I am afraid. The software tree is company wide and has to be so for good reasons. Count many (tens) thousands of files. No,
              Message 6 of 11 , Nov 7, 2000
                Bram Moolenaar wrote:
                >
                ...
                >
                > If you have 100 matching tags, you have a problem already. I would start by
                > finding a way to reduce the number of matches.
                >

                This is too simplistic view, I am afraid. The software tree is company
                wide
                and has to be so for good reasons. Count many (tens) thousands of files.
                No,
                it's not all the software, just the basis. It's very carefully handled
                but
                totally out of my control. Perfectly functional and integrated with many
                tools that dev needs to have. No need to go further.

                Cscope database is soft-dev wide (has to be) and has ~170 Mb. Everybody
                uses it, everybody has that "problem" (of many tags) (straight from
                cscope). Difficult
                to do otherwise. Cscope keeps list of tags, allows opening windows.
                Cscope integration with vim is *very* attractive.

                I am just after vim to make it even better.

                ...
                > Why not use ":tselect"?

                Hmmmm, never used it, will try...from the doc it *may* help, but it's
                'embedded'
                into the 'vim tag philosophy' (no pun intended!!!!) so it will likely
                not be
                a panacea. But I'll give it a shot.
                Thanks for hint.

                ...
                >
                > This is too vague. "give you the tag"? You should be able to do most things
                > by splitting the window and jumping to the tag in that one. Then you have the
                > new position and can do whatever you want to do next.
                >

                Give me the file where it is and on which line of that file, of the tag
                I selected.
                That's all. With this I can do what I need/want.

                I know I can use (and do) split windows and all that for tags, however,
                some
                files by nature of them (ts=8) need wider window (vertical split is
                great here)
                for comfortable view, that's taken from my main window real estate,
                overlapping
                windows maybe a better choice, etc...

                There are many different reasons all may be considered bad/good
                depending on
                the side of the bar one wants to/has to stay. That's why I am talking
                about
                an additional functionality ("option", but I don't like this word, it's
                used
                for too many things)

                What I'd like to do is really simple, e.g.: map <C-]> xterm -e vim
                -'that tag'
                (whatever syntax), but I need that tag line. Nothing complicated.
                Or an option(???again???) by which that 'match tag display' isn't an
                interactive
                display but goes to a (split?) window as an ordinary file. Than, of
                course,
                I have all the tools to do with it whatever I want.

                ...
                >
                > It's a generic idea of having a window where you can select items from a list.
                > The quickfix window is like that. For tags we would have to generate an error
                > list from the tag matches.
                >

                Right, now I remember something along those lines.
                But that's a sophisticated solution compared to my simple minded
                approach. this
                will surely need some appropriate thinking...Sounds very attractive,
                though.

                > > Anyway, somebody might remember, if not take this as a new question.
                > > Could anything like this be expected in vim6?
                >
                > Not much. I'm starting to cut down on adding new features and first finish
                > the things that are half-finished. I want to get 6.0 ready for release.
                >

                Sounds reasonable.

                Q: what happened to that option allowing 'set tags=**' to take all tag
                files
                from the current dir up to some root through the tree? The almost
                fully
                functioning patch was existing in vim-dev some time ago, forgot who
                made
                it (Ralph Schandle, perhaps?)

                ---Zdenek
              • Bram Moolenaar
                ... I doubt that when you are looking for a tag you need to consider all the files. You should at least be able to make a tags file for a selection of files
                Message 7 of 11 , Nov 7, 2000
                  Zdenek Sekera wrote:

                  > > If you have 100 matching tags, you have a problem already. I would start
                  > > by finding a way to reduce the number of matches.
                  >
                  > This is too simplistic view, I am afraid. The software tree is company wide
                  > and has to be so for good reasons. Count many (tens) thousands of files.
                  > No, it's not all the software, just the basis. It's very carefully handled
                  > but totally out of my control. Perfectly functional and integrated with many
                  > tools that dev needs to have. No need to go further.

                  I doubt that when you are looking for a tag you need to consider all the
                  files. You should at least be able to make a tags file for a selection of
                  files (filter it through grep?).

                  > Give me the file where it is and on which line of that file, of the tag I
                  > selected. That's all. With this I can do what I need/want.

                  You have that, just jump to the tag and the current file and the cursor
                  position are at the right position.

                  Another solution, if you're using cscope, is to do some cscope query to find
                  the position.

                  > What I'd like to do is really simple, e.g.: map <C-]> xterm -e vim -'that tag'
                  > (whatever syntax), but I need that tag line. Nothing complicated.

                  Didn't try this, but it should give you an idea:

                  :noremap <C-]> :call Xtag(expand("<cword>"))<CR>
                  fun Xtag(tag)
                  exe ":stag ". a:tag
                  " now we are at the file and position of the tag
                  exe '!xterm -e "vim +' . line(".") . @%
                  close
                  endfun

                  Should add some error handling for when the tag doesn't have a match.

                  > Q: what happened to that option allowing 'set tags=**' to take all tag files
                  > from the current dir up to some root through the tree? The almost fully
                  > functioning patch was existing in vim-dev some time ago, forgot who made
                  > it (Ralph Schandle, perhaps?)

                  It has been included and should work.

                  --
                  hundred-and-one symptoms of being an internet addict:
                  43. You tell the kids they can't use the computer because "Daddy's got work to
                  do" and you don't even have a job.

                  /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                  \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                • Zdenek Sekera
                  ... Right, but not until I know at least roughly where a given problem might come from.... ... Well, I have a yet simpler solution: jump to the tag and if its
                  Message 8 of 11 , Nov 7, 2000
                    Bram Moolenaar wrote:
                    >
                    > Zdenek Sekera wrote:
                    >
                    ...
                    >
                    > I doubt that when you are looking for a tag you need to consider all the
                    > files. You should at least be able to make a tags file for a selection of
                    > files (filter it through grep?).
                    >

                    Right, but not until I know at least roughly where a given problem might
                    come from....

                    > > Give me the file where it is and on which line of that file, of the tag I
                    > > selected. That's all. With this I can do what I need/want.
                    >
                    > You have that, just jump to the tag and the current file and the cursor
                    > position are at the right position.
                    >
                    > Another solution, if you're using cscope, is to do some cscope query to find
                    > the position.
                    >

                    Well, I have a yet simpler solution: jump to the tag and if its' the one
                    I want,
                    take the file name and open a new (=additional) vim session with that
                    file
                    name (cut & paste). Not quite the right technology I'd like,
                    though...:-):-)
                    But that's how I do it.

                    ...
                    > Didn't try this, but it should give you an idea:
                    >
                    > :noremap <C-]> :call Xtag(expand("<cword>"))<CR>
                    > fun Xtag(tag)
                    > exe ":stag ". a:tag
                    > " now we are at the file and position of the tag
                    > exe '!xterm -e "vim +' . line(".") . @%
                    > close
                    > endfun
                    >
                    > Should add some error handling for when the tag doesn't have a match.
                    >


                    Hmmmm...that's an idea! Quite tricky, so you open a window with a tag
                    and when
                    you know where you are fire off the xterm and kill the 'tag window'.
                    Hope
                    it doesn't do too much distracting movements with existing windows, but
                    it's
                    very interesting! Will surely need more refinements (include :ta, ...
                    error
                    handling as you said), but this *may* be a right start. Will try to
                    develop
                    that!

                    > > Q: what happened to that option allowing 'set tags=**' to take all tag files
                    > > from the current dir up to some root through the tree? The almost fully
                    > > functioning patch was existing in vim-dev some time ago, forgot who made
                    > > it (Ralph Schandle, perhaps?)
                    >
                    > It has been included and should work.

                    Haven't found a word about it in :h tags, :h 'tags', and some others
                    (vim60l),
                    that's why my question. Where is it?

                    ---Zdenek
                  • Matt Armstrong
                    ... I have my tags set to ./tags; and have the behavior you describe (vim searches for tags in the dir with the file all the way up to the root). -- matt
                    Message 9 of 11 , Nov 7, 2000
                      On Tue, Nov 07, 2000 at 02:43:13PM +0100, Zdenek Sekera wrote:
                      > > > Q: what happened to that option allowing 'set tags=**' to take all
                      > > > tag files from the current dir up to some root through the tree?
                      > > > The almost fully functioning patch was existing in vim-dev some
                      > > > time ago, forgot who made it (Ralph Schandle, perhaps?)
                      > >
                      > > It has been included and should work.
                      >
                      > Haven't found a word about it in :h tags, :h 'tags', and some others
                      > (vim60l), that's why my question. Where is it?

                      :h file-searching (which is pointed to by :h 'tags').

                      I have my tags set to "./tags;" and have the behavior you describe (vim
                      searches for tags in the dir with the file all the way up to the root).

                      --
                      matt
                    • Bram Moolenaar
                      ... From runtime/doc/version6.txt : Search Path *new-search-path* ... - Support upward search for path , cdpath and tags options. Also use ** for
                      Message 10 of 11 , Nov 7, 2000
                        Zdenek Sekera wrote:

                        > > > Q: what happened to that option allowing 'set tags=**' to take all tag
                        > > > files from the current dir up to some root through the tree? The almost
                        > > > fully functioning patch was existing in vim-dev some time ago, forgot
                        > > > who made it (Ralph Schandle, perhaps?)
                        > >
                        > > It has been included and should work.
                        >
                        > Haven't found a word about it in :h tags, :h 'tags', and some others
                        > (vim60l), that's why my question. Where is it?

                        From "runtime/doc/version6.txt":

                        Search Path *new-search-path*
                        -----------

                        - Support upward search for 'path', 'cdpath' and 'tags' options. Also use
                        "**" for 'tags' option. (Ralf Schandl)


                        Below ":help 'tags'":

                        "*" and "**" Wildcards can be used to search for tags files in a
                        directory tree. See |file-searching|. {not available when compiled
                        without the |+path_extra| feature}


                        Isn't that enough?

                        --
                        hundred-and-one symptoms of being an internet addict:
                        46. Your wife makes a new rule: "The computer cannot come to bed."

                        /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                        \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                      • Zdenek Sekera
                        Matt Armstrong wrote: ... Thanks, missed it.
                        Message 11 of 11 , Nov 8, 2000
                          Matt Armstrong wrote:
                          ...
                          >
                          > :h file-searching (which is pointed to by :h 'tags').

                          Thanks, missed it.

                          ---Zdenek
                        Your message has been successfully submitted and would be delivered to recipients shortly.