ripgrep

Whenever a Vim post mentions grep, ack or ag — especially in conjunction with fzf/fzy — I'll make sure to mention the even faster rg (ripgrep): https://github.com/BurntSushi/ripgrep BurntSushi's write-up about the internal workings of ripgrep is also super interesting: http://blog.burntsushi.net/ripgrep/) It's a really amazing piece of software. It has also recently been included in Visual Studio Code to search in files.

Arch is already packaging Rust applications. One of mine is in the community repo. People are working on debs, but it's slow going: https://github.com/BurntSushi/ripgrep/issues/10

Pretty sure that's already happening with tools like ripgrep: https://github.com/BurntSushi/ripgrep

I added ctrl-P bind to open with vim. But if I realize I didn't want to do that and want to cancel then hitting ESC or ctrl-c just drops me into vim with no file. Any ideas on how to change that bind so that I can cancel back to the command line? Edit: actually it's even worse, it seems like rg keeps running in the background even after I ctrl-c, which if I'm starting in some directory at the top of my directory tree means it runs for a long time. Edit 2: Looks like the problem in my edit is a known issue with ripgrep: https://github.com/BurntSushi/ripgrep/issues/200

RipGrep doesn't have some very useful PCRE features. https://github.com/BurntSushi/ripgrep#why-shouldnt-i-use-rip... If you use lookarounds (or often use grep -P), RipGrep may not cover all of your needed use cases. That said, it's very fast for general use.

Hope you don't mind some brief clarifications. Work on adding ripgrep to Linux distros is being tracked here[1]. We've made good progress so far, but AFAIK it's still missing in Ubuntu and Debian. I'm not caught up with what's required to get ripgrep into those repos. With respect to making it a literal default---as in replacing GNU grep---I don't really expect that to ever happen. There is a ton of intersection between the tools, right down to the names and functionality of flags, but there's also many subtle details in the differences. For example, normal grep invocations will use BREs by default, which have different escaping rules than EREs, where EREs are closer to what ripgrep uses. There's also the difference where ripgrep respects things like .gitignore and ignores hidden files by default, which means there's likely a non-zero num

Interesting read, I've been using Vim for some 18 years myself and I was completely unaware of fzf. However, I'm curious if you know `rg` (aka. ripgrep): https://github.com/BurntSushi/ripgrep In my experience it's markedly faster than `ag` (which is markedly faster than `grep`).

That's an interesting use case. You could use the `-l` flag to only list file names that match in combination with `-a` I suppose. That wouldn't let you see the non-binary matched lines though. In any case, I filed an issue[1]. I think the UX is pretty tricky to get right though. [1] - https://github.com/BurntSushi/ripgrep/issues/631

I haven't benchmarked them, but fd has a recursive parallel directory iterator. ag doesn't. The mysql-server repository[1] should be a fun one to try out, because of this: $ wc -l .gitignore 3122 .gitignore The combination of fast glob matching[2] and parallel traversal should be a boon. [1] - https://github.com/mysql/mysql-server [2] - https://github.com/BurntSushi/ripgrep/blob/e7c06b92fb996adcb...

It would be nice to have a collection of modern/faster/saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool) exa: https://the.exa.website/ (ls) una: https://github.com/jwiegley/una (multi-compression utils wrapper) tokei: https://github.com/Aaronepower/tokei (loc stats) And of course this: https://github.com/uutils/coreutils

Thank you for the feedback! Most of the credit for the speed goes to the amazing Rust modules 'ignore' and 'regex', which are also used by ripgrep (https://github.com/BurntSushi/ripgrep).

From its README: rg --type-add 'foo:*.{foo,foobar}' -tfoo bar --- You simply make the below into an alias: rg --type-add 'foo:*.{foo,foobar}' Or, if the type you need is generic that other users can also use, submit a PR. The developer was kind to except mine.. https://github.com/BurntSushi/ripgrep/pull/107/files .. it's a trivial 1-line PR.

Thoughts have crossed my mind, but it's a wickedly hard problem. My personal opinion is that once you start trying to solve the problem you're describing, then you really start to venture away from "line oriented searcher" to "code aware searcher" in a way that invites a lot of trade offs. The most important trade off is probably maintenance or complexity of the code. In particular, in order to better show results, I kind of feel like the search tool needs to know something about what it's showing. Right? How else do you intelligently pick the context window for each search result? For code, maybe it's the surrounding function, for example. The grep -C crutch (which is also available in ripgrep) is kind of the best I've got for the moment for a strictly line oriented searcher. `git grep` has some interesting bits in it that will actually

The README contains a quick breakdown: https://github.com/BurntSushi/ripgrep#quick-examples-compari... My blog post linked elsewhere goes into more detail, although I left out ack because it was too slow.