6 ms·

fzy[1] is a less bloated alternative, written in C. fzf is neat, but it does too much. [1]: https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy

by icy 6y ago

jclulow 6y ago
But does it really? Can one not simply not use the features one doesn't need? Also, I fully appreciate not rewriting things that are C and already working just because -- but surely if something is already written in a safer language then C isn't really a step forward either.
ithrow 6y ago
Yeah, well, that's just, like, your opinion...
kenhwang 6y ago
There's also skim[1], which would be a Rust fzy alternative. But neither fzy nor skim quite do what fzf does, which is offer an simple feature-filled experience out of the box. The big draw is fzf Just Works™. I don't mind that it feels bloated and slow sometimes, because I don't want to spend a week figuring out how to make the other two do what fzf does without configuration or drama, and all the speed improvements in the world doesn't really matter when the bottleneck is the meatball behind the keyboard. [1]https://github.com/lotabout/skim https://github.com/lotabout/skim
- forrestthewoods 6y ago
  I really wish skim ran on Windows :(
  - kenhwang 6y ago
    There's always WSL ¯\_(ツ)_/¯
bhaak 6y ago
The real advantage of fzy over fzf is that fzy is actually better at guessing what you want (the documentation claims it's also faster but I never noticed a difference). That fzy also forces you to think about good input providers (like fd instead of find) is just following the Unix philosophy of one tool doing what it's best at.
jbrnh 6y ago
fzf never struck me as the slightest bit slow. What am I doing wrong? You can configure it with an external previewer that can of cause be arbitrarily slow or bloated but you can hardly fault fzf for that.
- gpanders 6y ago
  In my experience fzf actually feels faster simply because it’s able to begin populating the output list before it finishes reading the input list. This means you get selection options immediately, whereas with fzy there can be a delay. This is particularly noticeable when working with large inputs (e.g. anything in the Linux kernel)

fzy[1] is a less bloated alternative, written in C. fzf is neat, but it does too much. [1]: https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy

by icy 6y ago

fzy[1] is a less bloated alternative, written in C. fzf is neat, but it does too much. [1]: https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy

jclulow 6y ago

But does it really? Can one not simply not use the features one doesn't need? Also, I fully appreciate not rewriting things that are C and already working just because -- but surely if something is already written in a safer language then C isn't really a step forward either.

ithrow 6y ago

Yeah, well, that's just, like, your opinion...

kenhwang 6y ago

There's also skim[1], which would be a Rust fzy alternative. But neither fzy nor skim quite do what fzf does, which is offer an simple feature-filled experience out of the box. The big draw is fzf Just Works™. I don't mind that it feels bloated and slow sometimes, because I don't want to spend a week figuring out how to make the other two do what fzf does without configuration or drama, and all the speed improvements in the world doesn't really matter when the bottleneck is the meatball behind the keyboard. [1]https://github.com/lotabout/skim https://github.com/lotabout/skim

forrestthewoods 6y ago
I really wish skim ran on Windows :(
- kenhwang 6y ago
  There's always WSL ¯\_(ツ)_/¯

bhaak 6y ago

The real advantage of fzy over fzf is that fzy is actually better at guessing what you want (the documentation claims it's also faster but I never noticed a difference). That fzy also forces you to think about good input providers (like fd instead of find) is just following the Unix philosophy of one tool doing what it's best at.

jbrnh 6y ago

fzf never struck me as the slightest bit slow. What am I doing wrong? You can configure it with an external previewer that can of cause be arbitrarily slow or bloated but you can hardly fault fzf for that.

gpanders 6y ago
In my experience fzf actually feels faster simply because it’s able to begin populating the output list before it finishes reading the input list. This means you get selection options immediately, whereas with fzy there can be a delay. This is particularly noticeable when working with large inputs (e.g. anything in the Linux kernel)