Live data from Hacker News

How FZF and ripgrep improved my workflow

medium.com

61–70 of 89 posts

Re: How FZF and ripgrep improved my workflow

#61
post #48

fzy[1], which is written in C, seems to be slightly faster: $ hyperfine --warmup 2 -r 10 'rg --files | fzy -e hello' 'rg --files | fzf -f hello' Benchmark #1: rg --files | fzy -e hello Time (mean ± σ): 153.6 ms ± 57.9 ms [User: 399.2 ms, System: 96.9 ms] Range (min … max): 85.9 ms … 244.3 ms 10 runs Benchmark #2: rg --files | fzf -f hello Time (mean ± σ): 210.5 ms ± 61.6 ms [User: 443.3 ms, System: 90.9 ms] Range (mi…

There's a big difference in how their matching works, that made me prefer fzf. It's related to how they deal with spaces.

With fzf, and also helm in Emacs, rofi... a space is a separator between matchers, and the order of the matchers does not matter. So if you type "foo bar", it will select a path "/bar/bla/foo" just fine. This is important to me for discoverability: very often you know quite well what keywords to look for, but you don't know or are not sure about the order. So order irrelevance is very important.

fzy treats the space as a literal. So the order matters. And that's a killer for me. Plus in my experience the speed difference is not important, all are fast enough in practice.

Re: How FZF and ripgrep improved my workflow

#62
post #18

Fuzzy down selection (fzf) is the big win. In Emacs that would be Helm of swiper. Instead of local completion (tab tab tab ;) do a global search, and narrow down interactively using fuzzy selection. It's really a different experience, a bit disconcerting at first (tab built into muscle memory), but it quickly becomes a one way change. No way I'd let go of fuzzy selection now. The connection with ripgrep is that fuzzy…

> but it quickly becomes a one way change. I've been using Helm for a couple of years, and it has crippled all other editors and IDEs for me. I never read the manual, I have no idea how Helm works, or what it does, or what it is supposed to do. Yet I do use it all day every day. I just type, and Helm delivers what I meant, blazingly fast. I've tried Atom, VSCode, Eclipse, CLion, Visual Studio, Xcode... I can't use th…

Sounds amazing. Would https://github.com/emacs-helm/helm/blob/master/README.md be the correct starting point for learning more about Helm?

Re: How FZF and ripgrep improved my workflow

#63
I use workflows in Alfred[0] for finding files, navigating to pages, and searching around a multitude of other customized datasets. The advantage I have with that over a fzf, at least for me, is being able to search instantly with a Cmd+Space without having to switch to the terminal.

[0] https://www.alfredapp.com/workflows/

Re: How FZF and ripgrep improved my workflow

#64
Fun fact about ripgrep: it's built into Visual Studio Code - it's why the "find in files" feature runs so fast.

Which means that if you run VS Code on OS X you actually have ripgrep installed already - just run the following:

    /Applications/Visual\ Studio\ Code.app/Contents/Resources/app/node_modules.asar.unpacked/vscode-ripgrep/bin/rg

Re: How FZF and ripgrep improved my workflow

#65

Earlier quoted context omitted.

> but it quickly becomes a one way change. I've been using Helm for a couple of years, and it has crippled all other editors and IDEs for me. I never read the manual, I have no idea how Helm works, or what it does, or what it is supposed to do. Yet I do use it all day every day. I just type, and Helm delivers what I meant, blazingly fast. I've tried Atom, VSCode, Eclipse, CLion, Visual Studio, Xcode... I can't use th…

Sounds amazing. Would https://github.com/emacs-helm/helm/blob/master/README.md be the correct starting point for learning more about Helm?

No idea. I just use spacemacs, and there it is enabled by default.

Re: How FZF and ripgrep improved my workflow

#66
> It performs amazing even in a larger code base.

Doubt ripgrep it will beat indexing, line GNU id-utils. (mkid to build ID file, lid to query).

If you're using git, "git grep" is useful; it searches only files indexed in git, which provides a useful speedup.

Re: How FZF and ripgrep improved my workflow

#68

Earlier quoted context omitted.

Why would choose such a terrible text editor then?

Honestly? I derive pleasure from hard work. I'm somewhat of a masochist in that way, I guess. I shun convenience and choose the hard path towards personal enlightenment.

Oh yeah? Then try coding in word...

Re: How FZF and ripgrep improved my workflow

#69

How does ripgrep compare to silversearcher-ag for performance?

I did an extensive comparison a while ago: https://blog.burntsushi.net/ripgrep/ --- It should still largely be pretty accurate (and ripgrep has only gotten faster). More generally, if someone can find a non-trivial example of ag being faster then ripgrep, then I'd love to have a bug report. (Where non-trivial probably means something like "not I/O bound" and "not so short that the differences are human imperceptible…

I'm currently working on a searcher on my own: https://github.com/elsamuko/fsrc

When I started, I didn't know ripgrep, now I use it as reference. Of course it's still slower for regex searches and it has less options, but in some cases (e.g. simple string matching search), it is faster than rg (PM_RESUME in 160-170ms), mostly thanks to mischasan's fast strstr: https://mischasan.wordpress.com/2011/07/16/convergence-sse2-...

If you want, let me know, what you think about it.

Re: How FZF and ripgrep improved my workflow

#70

Earlier quoted context omitted.

Why would choose such a terrible text editor then?

Honestly? I derive pleasure from hard work. I'm somewhat of a masochist in that way, I guess. I shun convenience and choose the hard path towards personal enlightenment.

Curious what the rest of your dev env is...
Post reply on HN