How FZF and ripgrep improved my workflow • Hacker News Board

Re: How FZF and ripgrep improved my workflow

#81

Post by thekelvinliu » Fri, Jul 05, 2019, 6:45 PM UTC

archy_ wrote: post #71

I see these Vim-enhancment posts a lot. If you need to install a mountain of plugins just to make it usable, why not use a more modern editor? Seems like nostalgia for the Unix greybeard era, possibly some eletism for when someone who isn't intimately familiar with their config has to ask for help to use their machine.

can't speak for everyone, but as a software engineer, it's about getting as close to my ideal editing workflow as possible. with vim i get to stay in my terminal, and my fingers rarely leave home row. it's just quicker to do things and hard to go back once muscle memory sets in.

and since i write code for a living, the time spent hacking vim to work just how i want it to is definitely worth it. with a "modern editor" i'd probably spend a similar amount of time configuring it to be vim-like, so might as well use the real thing :) i use neovim tho lol

Re: How FZF and ripgrep improved my workflow

#82

Post by burntsushi » Fri, Jul 05, 2019, 7:16 PM UTC

elsamuko wrote: post #75

burntsushi wrote: post #74

Earlier quoted context omitted.

I don't see any build instructions, so I don't know how to try it. Sorry. I did run `./scripts/build_boost.sh`, but that didn't produce any `fsrc` binary that I could use. I would also caution you to make sure you're benchmarking equivalent workloads.

There are no build instructions yet, you need to build boost with build_boost.sh and then open qmake/fsrc.pro with Qt Creator. There are binaries available here, too: https://github.com/elsamuko/fsrc/releases And I know than benchmarking is hard, a coarse comparison is in scripts/compare.sh. More detailed performance tests are in test/TestPerformance.

I don't know what Qt Creator is. Please provide tools to build your code from the command line.

I did some playing around with your binary, but it's pretty hard to benchmark because I don't know what your tool is doing with respect to .gitignore, hidden files and binary files. Your output format is also non-standard and doesn't revert to a line-by-line format when piped into another tool, so it's exceptionally difficult to determine whether the match counts are correct. Either way, I don't see any evidence that fsrc is faster. That you're using a fast SIMD algorithm is somewhat irrelevant; ripgrep uses SIMD too.

On my copy of the Linux checkout (note the `-u` flags passed to ripgrep):

    $ time /tmp/fsrc PM_RESUME | wc -l
    41

    real    0.143
    user    0.330
    sys     0.474
    maxmem  67 MB
    faults  0

    $ time rg -uuu PM_RESUME | wc -l
    17

    real    0.149
    user    0.564
    sys     0.690
    maxmem  13 MB
    faults  0

    $ time rg -uu PM_RESUME | wc -l
    17

    real    0.112
    user    0.481
    sys     0.675
    maxmem  13 MB
    faults  0

    $ time rg -u PM_RESUME | wc -l
    17

    real    0.118
    user    0.507
    sys     0.701
    maxmem  13 MB
    faults  0

    $ time rg PM_RESUME | wc -l
    17

    real    0.142
    user    0.749
    sys     0.726
    maxmem  21 MB
    faults  0

I originally tried to run `fsrc` on a single file (in order to better control the benchmark), but I got an error:

    $ time /tmp/fsrc 'Sherlock Holmes' /data/benchsuite/subtitles/2018/OpenSubtitles2018.raw.sample.en
    Error  : option '--term' cannot be specified more than once
    Usage  : fsrc [options] term
    Options:
      -h [ --help ]         Help
      -d [ --dir ] arg      Search folder
      -i [ --ignore-case ]  Case insensitive search
      -r [ --regex ]        Regex search (slower)
      --no-git              Disable search with 'git ls-files'
      --no-colors           Disable colorized output
      -q [ --quiet ]        only print status


    Build : v0.9 from Jul  5 2019
    Web   : https://github.com/elsamuko/fsrc

    real    0.005
    user    0.002
    sys     0.002
    maxmem  9 MB
    faults  0

Re: How FZF and ripgrep improved my workflow

#83

Post by IronBacon » Fri, Jul 05, 2019, 7:26 PM UTC

wstuartcl wrote: post #51

IronBacon wrote: post #46

Using FZF to search the shell history is great until you don't find the command you were searching, you need to abort and what you typed is canceled. That's my only gripe with it. I've tried to play with Zsh's Zle but wasn't able to find a way to abort FZF and retain the input, I suppose I need to modify FZF itself. If there's a way to do it with Zsh I'm all ears...

can you explain what you are looking for i na little more detail?

I'll try.

I'm using Zsh, Ctrl-r is bound to fzf-history-widget. I start the history search with Ctrl-r using fuzzy as default, I input the command but it's not present in the history and something unrelated is selected, if I press Ctrl-g to abort the original input is erased.

I've found at least a couple of feature requests (#389 #993) where it's suggested to bind a shortcut to the --print-query function.

I think I've tried it in the past without success but having a fresh look at it right now, I think the blame is to the fzf-history-widget in the binary way it tries fetch an history line or reset the zle prompt...

Re: How FZF and ripgrep improved my workflow

#84

Post by IronBacon » Fri, Jul 05, 2019, 7:33 PM UTC

fluffything wrote: post #57

IronBacon wrote: post #46

Using FZF to search the shell history is great until you don't find the command you were searching, you need to abort and what you typed is canceled. That's my only gripe with it. I've tried to play with Zsh's Zle but wasn't able to find a way to abort FZF and retain the input, I suppose I need to modify FZF itself. If there's a way to do it with Zsh I'm all ears...

In Helm you can go back and forth as much as you want. Sometimes you end up in a dark alley, and you are just key press away from stepping back out and trying somewhere else.

Emacs Helm? I'm so used to ido... ^__~

Re: How FZF and ripgrep improved my workflow

#85

Post by vindarel » Fri, Jul 05, 2019, 8:21 PM UTC

luckman212 wrote: post #62

fluffything wrote: post #55

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?

Yes. I also like

- http://wikemacs.org/wiki/Helm and http://wikemacs.org/wiki/Helm-swoop

- which link to an extensive tutorial: https://tuhdo.github.io/helm-intro.html

and +1 for Spacemacs: http://spacemacs.org/ (see other starter kits: http://wikemacs.org/wiki/Starter_Kits

Re: How FZF and ripgrep improved my workflow

#86

Post by hwj » Sat, Jul 06, 2019, 7:31 AM UTC

yaantc wrote: post #61

hwj wrote: 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 l…

Thanks for pointing this out. I guess fzy's primary goal is path matching which might explain this behaviour.

Re: How FZF and ripgrep improved my workflow

#87

Post by cannabis_sam » Sat, Jul 06, 2019, 11:14 AM UTC

roryrjb wrote: post #7

I can't really fault both of these tools at all. They have good defaults and are easy to configure and are well documented. Of course they are very performant too, but if you take the time to configuring your wildignore, learn how to use find's and rgrep's flags (maybe script some of this with shell or vimscript if necessary) you can get close to the performance of these tools and define your own usability if needed.…

>especially when you are using lots of different machines.

I always get into trouble due to inconsistencies across unix environments, and still don’t understand all the different greps I’ve encountered. I absolutely love these newer tools that shed all the attempts at unix-grey-beard backwards-compatibility..

(This is ofc completely subjective)

Re: How FZF and ripgrep improved my workflow

#88

Post by elsamuko » Sat, Jul 06, 2019, 4:11 PM UTC

burntsushi wrote: post #82

elsamuko wrote: post #75

Earlier quoted context omitted.

There are no build instructions yet, you need to build boost with build_boost.sh and then open qmake/fsrc.pro with Qt Creator. There are binaries available here, too: https://github.com/elsamuko/fsrc/releases And I know than benchmarking is hard, a coarse comparison is in scripts/compare.sh. More detailed performance tests are in test/TestPerformance.

I don't know what Qt Creator is. Please provide tools to build your code from the command line. I did some playing around with your binary, but it's pretty hard to benchmark because I don't know what your tool is doing with respect to .gitignore, hidden files and binary files. Your output format is also non-standard and doesn't revert to a line-by-line format when piped into another tool, so it's exceptionally diffic…

I included qmake and added a `deploy.sh` in the main source folder, which generates the deployed zip file. Let me know, if this doesn't build.

  * gitignore behaviour: If there is a .git folder in the search folder, it uses git ls-files to get all files to search in
  * a .git folder itself is never searched
  * hidden folders and files are searched
  * binaries are ['detected'](https://github.com/elsamuko/fsrc/blob/f1e29a3e24e5dbe87908c4ca84775116f39f8cfe/src/utils.cpp#L93), if they contain two binary 0's within the first 100 bytes or are PDF or PostScript files.
  * pipe behaviour is not implemented yet
  * it supports only one option-less argument as search term
  * folders are set with -d

Re: How FZF and ripgrep improved my workflow

#89

Post by JetSpiegel » Sat, Jul 06, 2019, 11:36 PM UTC

yaantc wrote: 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…

For (Neo)Vim, the plugin you are looking for is Denite, it can be cajoled into using fzf, rg, whatever external process you need. It's a game-changer.