On Wed, Sep 1, 2010 at 11:39 PM, Gary Johnson <[email protected]> wrote:
> On 2010-08-31, Britton Kerin wrote:
>> Hello,
>>
>> I only fairly recently found out about :copen :lopen etc.  Some snippets 
>> using
>> them are popular on vim_use:
>>
>>     
>> http://groups.google.com/group/vim_use/browse_thread/thread/211ed834076e7526/9f756b498db39636?lnk=gst&q=Run+lgrep+then+immediately+#9f756b498db39636
>>
>> At minimum, I think these commands deserve a pointer from the grep section
>> of quickfix.txt.  It can take years to find them otherwise.  I've attached
>> a patch which does this and also includes a command example.  I think
>> its worth including, because for me (and apparently some others at least)
>> the default :grep (and :lgrep and :helpgrep) behavior is somewhere between
>> painful and unusable.  In the past I've usually just ended up using the 
>> shell.
>>
>> Also, :grep! is usually more useful than :grep.  Jumping to the first error
>> usually makes sense when compiling but usually doesn't when grep'ing.  One 
>> does
>> in theory get led to a description of the !-form functionality when reading
>> the :grep documentation, so I'm not sure the docs can be regarded as needing
>> fixing.  But :grep! does make things behave better and odds are many people
>> don't find out about it.  The attached patch helps with this issue as well.
>>
>> There are two other problems I have with the way grep works in vim (and most
>> other editors for that matter):
>>
>>  * Its not easy to filter the grep results.  When a user needs to grep it
>>    usually means:
>>
>>       a. the project is biggish
>>
>>       b. they have little idea where the occurences they are interested
>>          in are located, and
>>
>>       c. there are likely multiple file types involved.
>>
>>    This means that much of the output of the grep is going to be
>>    uninteresting.  One can go back and change the file list, but its usually
>>    a hassle to get the list just right.  This is enough of a trouble for
>>    me that I often end up going to the terminal and tacking on a bunch of
>>    '| grep -v "junk_pattern"' things until I get what I want.
>>
>>  * Support for context is poor.  A single line is often not enough,
>>    but putting '-C 1'  in 'grepprg' makes :cn ~200% slower.
>>
>> I have a module that fixes these issues for me though its pretty messy
>> and fragile as it depends on slicing up, saving, :cgetfile'ing, reparsing,
>> and re-presenting the error file.
>>
>> I just mention them because they are issues I'd love to see vim address
>> properly someday.
>
> Just to present the other side of some of your issues:
>
> 1.  I never use :grep!.  When I :grep for something, I want to see
>    all occurrences of it in the context of the files in which it is
>    found, so I want to immediately jump to the first match.  I
>    often start :grep as
>
>        :new | grep ...
>
>    so that the matching files are opened in a new window.
>
> 2.  I agree that the default commands for traversing the quickfix
>    list can be painful.  I have ^N and ^P mapped to :cn and :cp
>    respectively so that jumping from one match to the next is a
>    breeze.
>
> 3.  If the output of a :grep command contains too many undesired
>    hits, use a better pattern or use the --include and --exclude
>    options to grep to limit the files searched.  If you find a lot
>    of hits in one file that you know aren't going to be
>    interesting, use :cnf to skip that file.

I missed this :cnf command, thanks for pointing it out.

> 4.  A little context for the matches would be nice, but again,
>    traversing the quickfix list with the ^N and ^P mappings is
>    fast and provides a full screen of context.
>
> Vim's :grep facility is not perfect, but I don't think it's as bad
> as you say, either.

Maybe I was a little harsh.  I've always found vim's grep interface
*almost* good enough that I wanted to use it.

Britton

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

Raspunde prin e-mail lui