On 2009-06-02, Edward Peschko wrote:
> > How do you expect that to be significantly faster than running grep
> > on the entire project? I don't mean vimgrep--I wouldn't use that
> > for this application, either--I mean plain old grep, invoked from
> > vim's :grep command.
>
> I can count four ways that this would be faster/easier to use than the
> current setup:
>
> 1. In places that use NFS, the files could be kept in local
> file store, which increases the speed of search by a factor of two or
> so. Even in fast access using grep requires the opening of a large
> number of data files.
>
> 2. the file format could be as you described, or something more
> exotic (as in mysql's FULLTEXT format, or preprocessing via
> Boyer Moore, both of which allow for much faster access than
> a serial format). Think Google Desktop or X1 search.
Good points. Thanks.
> 3. Projects commonly consist of real files interspersed between
> large, garbage or temporary files. Storage is also usually spread
> out across multiple directories. If one uses grep, one needs to
> remember/support a large, complicated grep command, and has
> to wade through several false negatives.
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.
> 4. Grep is 'suboptimal' when it comes to integration, and sts is much
> easier to use. Several files are opened in a MiniBufExplorer,
> and you need to type ':cn' and ':cp' to go between them. In the
> process, you lose your place (where you were editing) and you
> need to wade through them one at a time. Whereas with ':sts'
> you get a list of possible matches, and pick between them with
> a number. A lot simpler, and cleaner.
Here are a couple of things which would make your experience with
:grep much better.
First off, I have Ctrl-N and Ctrl-P mapped to :cn and :cp,
respectively. That makes traversing the quickfix list much easier.
Second, as for losing your place, I usually open a new window before
executing :grep, like this:
:new | grep somepattern
Third, the :copen command will open a window containing the quickfix
list. You can easily scroll through this list, or even search in
it, and when you press Enter, the target file will be opened in the
"other" window, with the cursor on the target line.
> 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.
There are a number of Vim plugins that allow access to various
indexes besides ctags and cscope: gtags.vim accesses GNU GLOBAL;
greputils.vim and lid.vim access GNU idutils. Those are just the
ones I happened to think of. You might see if any of those meet
your needs. Perhaps more important, though, these plugins
illustrate that, with a little Vim-script programming, one can make
Vim interface with just about any index. If you have used an index
you like on other projects, it might be possible to access it from
Vim.
> If I was to describe this in terms of a feature request, I'd say it was
> genericize the :sts command such that it could
>
> * be configured to work with an external command
> * have that external command be passed arguments from
> the command line (ie: :sts <regular expression> would pass
> <regular expression to this command)
> * take the results of that command and interpret them as a
> series of tags
> * provide a list of tags to the user to be displayed
> (as the current sts command) which they would then pick
> with a number.
> * provide a split vim session showing the text they picked.
>
> Call it ':taggrep'. In fact, it would work a lot like the current tags
> mechanism,
> only with a specialized command that provides the tags aside from ctags,
> and those tags are provided 'on the fly' to vim for parsing rather than from
> a file..
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.
> Again, indexes like these are life savers, it would just be nice if they were
> available via vim.
Thanks for taking the time to explain that. On the Linux servers
here at work, an ordinary grep, even of an NFS-mounted ClearCase
VOB, goes reasonably fast. Even so, it would be nice to be able to
search more quickly for words that aren't necessarily symbols, so if
you find or know of some such indexing tool, I'd be interested in
hearing about it.
Regards,
Gary
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
