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

Re: extending tags mechanism

Expand Messages
  • 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 1 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.