Comment by alexpasmantier | Hacker News Reader

Comment by alexpasmantier | Hacker News Reader

Parent Full thread

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