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

Re: extending tags mechanism

Expand Messages
  • Jason Axelson
    ... I m curious if you ve looked into using ack (http://www.betterthangrep.com/) for your grepprg. I would naively think that it would greatly simplify the
    Message 1 of 12 , Jun 2, 2009
    • 0 Attachment
      On Tue, Jun 2, 2009 at 12:29 PM, Gary Johnson <garyjohn@...> wrote:
      > Not if you define 'grepprg' appropriately.   I work on a number of
      > huge projects, with files spread across multiple directories and
      > among other files and directories that are of no interest to me.
      > For each project, I have a <project_name>_grep script that uses a
      > fairly complicated find command to find only the files I want to
      > search, piped to xargs and grep.  I have a plugin that "knows" which
      > project I'm working on and sets 'grepprg' to the corresponding
      > script.
      >
      > Yes, I have to support those scripts, but they are all similar to
      > one another, and I would have to similarly support any indexing tool
      > I used on those projects.

      I'm curious if you've looked into using ack
      (http://www.betterthangrep.com/) for your grepprg. I would naively
      think that it would greatly simplify the scripts that you mentioned.
      Of course, I could be totally off-base on this.

      Jason

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_use" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Gary Johnson
      ... I hadn t heard of it. I just looked at the web page. It looks like a great tool for some situations. Unfortunately, it appears to solve problems I don t
      Message 2 of 12 , Jun 2, 2009
      • 0 Attachment
        On 2009-06-02, Jason Axelson wrote:
        > On Tue, Jun 2, 2009 at 12:29 PM, Gary Johnson <garyjohn@...> wrote:
        > > Not if you define 'grepprg' appropriately.   I work on a number of
        > > huge projects, with files spread across multiple directories and
        > > among other files and directories that are of no interest to me.
        > > For each project, I have a <project_name>_grep script that uses a
        > > fairly complicated find command to find only the files I want to
        > > search, piped to xargs and grep.  I have a plugin that "knows" which
        > > project I'm working on and sets 'grepprg' to the corresponding
        > > script.
        > >
        > > Yes, I have to support those scripts, but they are all similar to
        > > one another, and I would have to similarly support any indexing tool
        > > I used on those projects.
        >
        > I'm curious if you've looked into using ack
        > (http://www.betterthangrep.com/) for your grepprg. I would naively
        > think that it would greatly simplify the scripts that you mentioned.
        > Of course, I could be totally off-base on this.

        I hadn't heard of it. I just looked at the web page. It looks like
        a great tool for some situations. Unfortunately, it appears to
        solve problems I don't have and doesn't solve the problems I do
        have.

        For example, our source code includes proprietary languages with
        suffixes that ack doesn't support. We also have directories of
        automatically-generated C code that I usually don't want to include
        in searches. I think by the time I adjusted ack for issues like
        this, that it wouldn't be any easier to use than find/xargs/grep or
        grep -R --include=etc.

        Regards,
        Gary



        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_use" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Edward Peschko
        ... hmm.. I just tried it, and you are right, it does make grep more tolerable, but it still is suboptimal. I suppose I could redefine :ngrep to do all the
        Message 3 of 12 , Jun 2, 2009
        • 0 Attachment
          >> I could probably think of more, but you get the idea. Having such an index
          >> is a life-saver; I've used it before on projects but would like the
          >> functionality accessible via vim, that's all.

          >
          > I think the :grep command along with the rest of the quickfix
          > features meets all those requirements.  Note that 'grepprg' doesn't
          > have to be set to grep or any other file-searching command--it can
          > just as easily be set to some command that accesses an index.
          > There's also a 'grepformat' option to tell Vim how to interpret the
          > output of 'grepprg' in case it's different from grep's format.

          hmm.. I just tried it, and you are right, it does make grep more
          tolerable, but it still
          is suboptimal. I suppose I could redefine :ngrep to do all the steps
          you describe,
          but the issue with copen, etc. is a bit hacky, UI wise. The main issue
          I have is that there is
          no fluid workflow..

          IE: in the quickfix list, you go to another line, and you need to
          press return to jump to the next item. Then, the focus switches
          automatically to the top window, and if you need to press CTRL-W W
          *twice* to get back to the quick list (assuming that you want to keep
          your place.

          Then, if you are continuing to edit, you move to the next line.

          So, in order to switch back and forth you need to type six edit mode
          commands, to move between windows..

          What would be better is a 'tracking' window, ie: where when you move
          from line to line, the top window is linked to the bottom, and you
          press 'return' to then switch focus. That way, the top window would
          always reflect the place where you were in the quickfix window..

          Even cooler would be a system for editing the quickfix window, and
          having those edits show up in the top window. That way, if you did a
          substitution in the bottom window (say replacing a variable for
          another variable) all of the changes that you'd make would
          automatically show up in the places where you'd like to see them, and
          you wouldn't need to make any extra movements at all.

          That would certainly trump the feature I had in mind..

          Ed

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_use" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Gary Johnson
          ... I won t argue with that. People s work flows and their ideas of what constitutes a smooth work flow seem to vary widely. It seems to depend a lot on the
          Message 4 of 12 , Jun 2, 2009
          • 0 Attachment
            On 2009-06-02, Edward Peschko wrote:
            > >> I could probably think of more, but you get the idea. Having such an index
            > >> is a life-saver; I've used it before on projects but would like the
            > >> functionality accessible via vim, that's all.
            >
            > >
            > > I think the :grep command along with the rest of the quickfix
            > > features meets all those requirements.  Note that 'grepprg' doesn't
            > > have to be set to grep or any other file-searching command--it can
            > > just as easily be set to some command that accesses an index.
            > > There's also a 'grepformat' option to tell Vim how to interpret the
            > > output of 'grepprg' in case it's different from grep's format.
            >
            > hmm.. I just tried it, and you are right, it does make grep more
            > tolerable, but it still is suboptimal. I suppose I could redefine
            > :ngrep to do all the steps you describe, but the issue with copen,
            > etc. is a bit hacky, UI wise. The main issue I have is that there
            > is no fluid workflow..

            I won't argue with that. People's work flows and their ideas of
            what constitutes a smooth work flow seem to vary widely. It seems
            to depend a lot on the tools they've gotten used to as well.

            > IE: in the quickfix list, you go to another line, and you need to
            > press return to jump to the next item. Then, the focus switches
            > automatically to the top window, and if you need to press CTRL-W W
            > *twice* to get back to the quick list (assuming that you want to keep
            > your place.

            I think you could use Ctrl-W p instead, to jump to the previous
            window. That might help a little.

            > Then, if you are continuing to edit, you move to the next line.
            >
            > So, in order to switch back and forth you need to type six edit mode
            > commands, to move between windows..

            I only use the quickfix window to jump to particular target lines
            when the number of found lines is very large. Otherwise, if I want
            to visit all or a large fraction of the found lines, I just traverse
            the list using :cn and :cp, mapped to single keystrokes. I don't
            switch back and forth very often.

            > What would be better is a 'tracking' window, ie: where when you move
            > from line to line, the top window is linked to the bottom, and you
            > press 'return' to then switch focus. That way, the top window would
            > always reflect the place where you were in the quickfix window..

            I suppose, although since the bottom, quickfix window does track the
            location in the top, edit window, you could move the cursor to the
            top window to traverse the list. One problem with having the top
            window track the highlighted line in the bottom window is that some
            files can take a long time to load--if they are long and syntax
            highlighting is enabled--and having to load them just to move the
            line in the quickfix window could slow down a search.

            > Even cooler would be a system for editing the quickfix window, and
            > having those edits show up in the top window. That way, if you did a
            > substitution in the bottom window (say replacing a variable for
            > another variable) all of the changes that you'd make would
            > automatically show up in the places where you'd like to see them, and
            > you wouldn't need to make any extra movements at all.

            Interesting. That would be especially nice if you could delete
            lines from the quickfix window that contained instances of a match
            you didn't want to change, then apply a substitute command to the
            entire quickfix window, with the changes being applied to the target
            files as you describe.

            Regards,
            Gary



            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_use" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          Your message has been successfully submitted and would be delivered to recipients shortly.