ripgrep

To reproduce, first create a large binary file: And then try to search it with : It should not take that long. A quick peak at while the above process was running reveals it is doing a line-by-line search, probably because of some faulty reasoning about the line terminator in this case. Since most of the file is just line terminators, this spends a lot of time iterating over lines. I found this as part of #2831.

What version of ripgrep are you using? How did you install ripgrep? The tarball from the 14.1.1 release page. What operating system are you using ripgrep on? Linux (x86_64), git 2.55.0 as the reference. Describe your bug. A line consisting of a bare compiles to the glob marked as a whitelist. Since that matches everything, it re-includes the entire subtree below the file it appears in — including paths excluded by an ancestor , and including itself, which ripgrep otherwise never descends into. git treats the same line as a no-op: after stripping the there is no pattern left, so nothing is negated and the parent's rules keep applying. Nothing is printed on stderr; the only visible trace is under . What are the steps to reproduce the behavior? What is the actual behavior? → , is the whole bug in one line. Dropping the shows the other half: the full listing includes , , every and so on. The whitelist outranks the filter too. What is the expected behavior? not listed, and still skipped — a bare should leave no pattern behind, the way git handles it. Some controls, so the report is about the right thing Same tree, only changes. is the inherited-rule query; is one only can decide. Two things worth pulling out of that table: This is not the general "ripgrep rejects a pattern git accepts" complaint from #373 / #646 / #945. — the exact example in those threads — behaves correctly here in 14.1.1. The bare is a different shape: not rejected, but compiled into something that matches everything. Last-match-wins makes the position matter, which is what you would expect from a real whitelist entry and confirms it is being treated as one: after cancels , before it doesn't. A nested goes the same way as , so the effect covers the whole subtree, not just the directory holding the file. Where I hit it I maintain a conformance bench that replays real repositories' trees against as the oracle. ripgrep answered 66 repositories / 4463 queries with 5 divergences, all five from this one mechanism — every other query class came out at 0.0%. The five all came from , which carries a one-line in as a fixture for exactly this kind of file. Bench, corpus and the adapter: https://github.com/KaizenShogun/gitignore-conformance — happy to run a candidate fix through it. — Midas

This PR adds end-column information to "--vimgrep" output. Previously --vimgrep emitted: It now emits: The end column is derived from the match end offset and allows Vim to populate the quickfix "end_col" field when using: This also updates the existing vimgrep tests and adds coverage for UTF-8 matches, --no-column and multiline matches. Also Fixes #3532