Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ripgrep 15.0

github.com

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Ripgrep 15.0

#101

Post by burntsushi »

rurban wrote: post #98
burntsushi wrote: post #63

Earlier quoted context omitted.

Fewer bugs? And perf depends on your haystack size. If you have lots of data to search, it's not hard to witness a 10x difference: https://news.ycombinator.com/item?id=45629904 As for features that ripgrep has that ag doesn't: * Much better Unicode support. (ag's is virtually non-existent.) * Pluggable preprocessors with --pre. * Jujutsu support. * ripgrep can automatically search UTF-16 data. * ripgrep has PCRE2 sup…

But unicode support is still nuclear. In unicode you can write the same graphemes in many different ways. And if you go to non-unicode supported language specifics, like ue standing for ü, where the ü can be written in two different ways, with marks and directly, neither ripgrep nor ugrep will help find those substrings. Also the many Arabic subtleties, where there are not only mark combinations, but also more beauti…

Idk what "still nuclear" means.

And yes, ripgrep doesn't do any kind of Unicode normalization. Few tools do.

But that doesn't mean what I said was wrong. ripgrep has a whole host of Unicode features that ag doesn't have.

Re: Ripgrep 15.0

#102

Post by burntsushi »

jodleif wrote: post #99

Ive always found the silversearcher defaults (or perhaps -Q) to just work better. Any alias/config tips?

ripgrep's -Q is just -F, like grep. This is not enabled by default in either tool.

Otherwise, ag enables multiline search (assuming you have a version of ag where that even works) and smart case by default. With ripgrep, that's ` rg -US`.

Re: Ripgrep 15.0

#103

Post by sigmaml »

burntsushi wrote: post #101
rurban wrote: post #98

Earlier quoted context omitted.

But unicode support is still nuclear. In unicode you can write the same graphemes in many different ways. And if you go to non-unicode supported language specifics, like ue standing for ü, where the ü can be written in two different ways, with marks and directly, neither ripgrep nor ugrep will help find those substrings. Also the many Arabic subtleties, where there are not only mark combinations, but also more beauti…

Idk what "still nuclear" means. And yes, ripgrep doesn't do any kind of Unicode normalization. Few tools do. But that doesn't mean what I said was wrong. ripgrep has a whole host of Unicode features that ag doesn't have.

The GP probably meant "unclear".

Re: Ripgrep 15.0

#104

Post by burntsushi »

EnPissant wrote: post #97
burntsushi wrote: post #96

Earlier quoted context omitted.

I was extremely careful with my wording. Re-quoting, with added emphasis: > ripgrep should generally already be approximating `git ls-files` by respecting gitignore. See also: https://news.ycombinator.com/item?id=45629515

I'm just trying to be helpful, not call you out. I've implemented gitignore aware file scanning before, and it was slower than git native operations when you only care about tracked files. It's the speed that is the part I was speaking too, not the semantics.

Yes, I agree, `git ls-files` can indeed be faster than just `rg --files`. On my Chromium checkout:

    $ hyperfine --output pipe 'rg --files' 'git ls-files'
    Benchmark 1: rg --files
      Time (mean ± σ):     141.2 ms ±   7.1 ms    [User: 1134.5 ms, System: 376.3 ms]
      Range (min … max):   128.7 ms … 154.8 ms    20 runs

    Benchmark 2: git ls-files
      Time (mean ± σ):      54.9 ms ±   1.7 ms    [User: 41.7 ms, System: 13.1 ms]
      Range (min … max):    52.2 ms …  62.0 ms    54 runs

    Summary
      git ls-files ran
        2.57 ± 0.15 times faster than rg --files
But the semantics here are important, because ripgrep doesn't only try to approximate `git ls-files`. It also needs to deal with `.rgignore` and `.ignore`. And no git repository state will help there. ripgrep also supports respecting `.gitignore` even when it isn't inside a git repository.

Re: Ripgrep 15.0

#107

Post by tasuki »

thdhhghgbhy wrote: post #73
tasuki wrote: post #70

Earlier quoted context omitted.

You could have incorporated some snark or something, but no, you're always the most helpful you can be. You're very inspirational - thank you! (Also like thanks for ripgrep I guess?)

>You could have incorporated some snark Why even say this?

It was the first thing that came into my mind...

Re: Ripgrep 15.0

#108

Post by msephton »

I use ripgrep to search file listings from my collection of 500+ vintage Macintosh Magazine CD-ROMs (1 million files; 30 million unzipped. I'm no database programmer but I could get anywhere near the same ballpark of speed as ripgrep and regex is good enough for querying plain text files. https://news.ycombinator.com/item?id=43607153

Re: Ripgrep 15.0

#109

Post by thdhhghgbhy »

bombela wrote: post #84
thdhhghgbhy wrote: post #66

Earlier quoted context omitted.

Thanks for the response. I would like to use fzf with rg to search file contents with a previewer open. However when I first open fzf I don't wish to pass any argument to rg, until I start typing. Something like Telescope live_grep.

Similar to other answers. With a nasty mix of vimscript generating shell commands for fzf to use, that's how I integrated rg and fd with "fzf.vim" in my neovim. https://github.com/bombela/fzf.vim.rgfd Nasty, but it works hey!

Thank you, nice.

Re: Ripgrep 15.0

#110

Post by sshine »

burntsushi wrote: post #93
EliMdoza wrote: post #88

Earlier quoted context omitted.

been using both for many years now, have never ran into issues or even been able to tell any difference in speed, let alone 10x what I notice unfortunatly, is that I often miss search results with rg becuase I forget I need to pass the additional -i flag. this has shaped my perception of rg - extra focus on performance, sub-optimal ux

Whether smart case is enabled by default (as ag does) could easily go either way. Notably,.I think having it disabled by default is a better UX. But ripgrep does have a --smart-case flag, which you can add to an alias or a ripgrep config file. It also works more consistently than ag's smart case feature, which has bugs. See my other comments about perf difference. And ag has several very critical bugs. And it's unmai…

I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. Maybe there are similar directories that people prefer included by default.

Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it.

Post reply on HN