Television: Fast general purpose fuzzy finder TUI | Hacker News Reader

Television: Fast general purpose fuzzy finder TUI

github.com

92 pointsthunderbong30 comments

Bonus points for "written in Rust" not being in the first sentence.

I may give this a try and see how it compares to fzf.

To be fair it starts with "Blazing Fast" which very much gives it away

TBF when dealing with I/O using the right async constructs is way more important than the choice of programming language, I/O times will dominate and any mistake on the wrong wait will ruin performance.

Absolutely but "blazing fast" has become kind of a meme among rust projects. Getting a bit tired of seeing it everywhere personally, at least show me some benchmarks when you make claims like this.

No shade against this project (or rust in general) though, it looks very nice and I wanna try it out.

I think the blazing fast has become a meme at this point and people use it very tongue-in-cheek

...but is it web-scale?

Holy moly, forgot to add that too :p

Bonus points for the name being chosen after a bottle of whisky.

I look the gif and think, seems like Telescope, and continue reading its said the one inspiration came for that.

I love this way to find something out of the box, after telescope I never more use the file explorer.

This seems similar to fzf with a nice default experience (quick access to fuzzy search files, shell history, git log) and a subset of features.

I use fzf to hack together custom TUIs (a calculator, clipboard search, quick LLM chat). The killer feature for me is `--bind` to bind keys and events to custom actions.

The demo video is a bit fast, I couldn't really follow.

It looks like an fzf alternative?

Interesting. I’ve never found a fuzzyfinder that “just worked” on windows for fuzzy searching in files under the current directory. Will give it a shot.

Without trying to imply that this thing needs to be “different” from fzf, but how is it different, if at all? A comparison would be appreciated.

tv isn’t intended to be a direct competitor to fzf, but since the two share similarities, here’s a quick breakdown of how tv differs:

- Batteries-included experience: tv is designed to work out of the box, with minimal setup.

- Smart shell integration: Autocomplete intelligently selects the right source for you.

- Interactive data source switching: You can change the data source on the fly without exiting the application.

- Centralized configuration: All settings are managed in one place, eliminating the need for custom shell scripts.

- Transitions feature: Enables interactive piping of results through multiple steps (e.g., git-repos > files > textual content in files).

- Built-in syntax-highlighted previews: More robust and integrated compared to configuring something like fzf --preview 'bat -n --color=always {0}'.

That said, tv is still an early-stage project (while fzf has been evolving for over 11 years). I’m also planning to draw inspiration from some of fzf’s excellent features in the future.

Great work!

From the README:

> is designed to be easily extensible

Can you elaborate a little on that?

Television is designed with a "framework-like" approach in mind. Here’s what makes it easy to extend (in a nutshell):

- Custom Cable Channels: You’re not limited to the built-in channels. You can create your own "cable channels"—essentially custom data sources—by tweaking a simple config file. As the project grows, the vision is for users to contribute their own channel recipes to the wiki, making it easy for others to pick and choose what suits their needs.

- Smart Shell Integration: Television integrates seamlessly with your shell, offering features like smart autocomplete and interactive piping of results. It’s also fully customizable, so you can tweak the smart autocomplete behavior or other features to match your workflow.

- Coming Soon: User-definable custom actions within cable channel recipes for an even more streamlined and tailored experience.

This probably doesn’t answer everything, but I’d be happy to dive into more details about any of the points above! :-)

This is really wonderful and well made. The only change I'd make is to have the context window opened via ctrl + g to be on by default (w/ an option to toggle off).

two things about this: great work on the packaging side of things (I installed it through brew in seconds) and shell integration by default is a really really nice touch, it streamlines everything, great job

can I use this in neovim? Something like fzf.vim

I have created a vim plugin that works both in vim and neovim which you can find at https://github.com/prabirshrestha/tv.vim

Just added it to the showcase section https://github.com/alexpasmantier/television/wiki/Showcase if you wish to add any details :-)

Since I started using this, I have stop using Grep

i might give it a try the project looks well maintained with +1K stars

what is the tl;dr on this vs fzf?

tv's file previewer is active per default, for fzf you have to hack it via --preview arg. subjectively tv is searching faster and previewer works faster than the fzf-preview.sh

It is obvious that tv is blocking on file preview. I can hold up key and zip up and down in fzf. In tv it causes obvious jank, I guess it waits for every file to render. Fzf doesn't make this mistake because preview is async. It's a clear winner when input lag is concerned.

Author here—thanks for trying out tv and for sharing your feedback, I really appreciate it.

The preview window in tv is designed to compute its content asynchronously. This approach ensures smooth input handling and maintains overall UI responsiveness. You can test this yourself by using a custom preview command that simulates a delay, like so:

  tv --preview "sleep 1 && echo 'the preview'"

You'll notice that even with a delay, the UI remains responsive and doesn't block.

That said, I'm sure there's always room for improvement, and I'd be happy to hear your thoughts or suggestions if you're open to discussing it further.

I see preview renders after the cursor moved, but still cursor moves in jumps unlike fzf. Maybe if you focus on search you don't care about it.

I believe this is just a matter of framerate. You may increase it to make those jumps invisible to the human eye ('tv --frame-rate xx') but that inevitably comes with a cost in terms of cpu usage which tv tries to keep at a minimum.

This is primarily a matter of which tradeoff suits most users I guess :-)

I tried it with --frame-rate=60 but there was no change, still selection noticeably lags compared to fzf.

Maybe your preview is async but it feels like it is updated for almost every item while I scroll through the list. Fzf preview is debounced and updates after selection stops.

Also when I test it in a dir with a 100 MB text file fzf will become slightly less smooth when scrolling selection, kind of like tv. However in that dir "tv text" will completely fail and not find any string in that file.

Reply on news.ycombinator.com