well... it is not faster than qgrep :) even though the way both work - differs greatly, and even though qgrep is based on re2 - the speed comes from the presence of index. but then I wonder why people forget the qgrep option, since with large file stores it makes much more sense to use qgrep AND indices, rather than always go through all the files.
this above all true UNLESS you need multi-line matches with UTF8, where ripgrep is not so fast, because it needs to fall back to the other PCRE2 lib
Yes, qgrep uses indexing, which will always give it a leg up over other tools that don't use indexing. But of course, now you need to setup and maintain an index. The UX isn't quite as simple as "just run a search."
But there isn't much of a mystery here. Someone might neglect to use qgrep for exactly the same reason that "grep is fast enough for me" might prevent someone from using ripgrep. And indeed, "grep is fast enough" is very much true in some non-trivial fraction of cases. There are many many searches in which you won't be able to perceive the speed difference between ripgrep and grep, if any exists. And, analogously, the difference between qgrep and ripgrep. The cases I'm thinking of tend to be small haystacks. If you have only a small thing to search, then perhaps even the speed of a "naive" grep is fast enough.
So if ripgrep, say, completes a search of the Linux kernel in under 100ms, is that annoying enough to push you towards a different kind of tool that uses indexing? Maybe, depends on what you're doing. But probably not for standard interactive usage.
This is my interpretation anyway of your wonderment of (in your words) "why people forget the qgrep option." YMMV.
> this above all true UNLESS you need multi-line matches with UTF8, where ripgrep is not so fast, because it needs to fall back to the other PCRE2 lib
That's not true. Multiline searches certainly do not require PCRE2. I don't know what you mean by "with UTF8," but the default regex engine has Unicode support.
PCRE2 is a fully optional dependency of ripgrep. You can build ripgrep without PCRE2 and it will still have multiline search support.
Does `build.rs` build the project? One of my favorite (Big Corp) code-bases just had a single C file (build.c) that did all the dependency tracking, like, Make, but in some nicely written (easy to understand) C code. The C file started with a shebang: a self-building-and-executing line, so we'd do this:
No. Cargo does. The `build.rs` is basically a Cargo hook that gets compiled as a Rust program and executed just before the ripgrep binary is compiled. It lets you do things like set linker flags[1] so that you can embed an XML manifest into the binary on Windows to enable "long path support."
ripgrep's build.rs used to do more, like build shell completions and the man page. But that's now part of ripgrep proper. e.g., `rg --generate man` writes roff to stdout.
this above all true UNLESS you need multi-line matches with UTF8, where ripgrep is not so fast, because it needs to fall back to the other PCRE2 lib