Hacker News Reader

Comment by icy | Hacker News Reader

fzy[1] is a less bloated alternative, written in C. fzf is neat, but it does too much.

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

I really wish skim ran on Windows :(

There's always WSL ¯\_(ツ)_/¯

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.

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.

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)

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.

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

Reply on news.ycombinator.com