Closed natecraddock closed 1 month ago
Hey, thank you for the project. I am looking to replace fzf with zf.
The preview feature is actually one of the most important features for me, I use it to preview the contents of files when I use fzf in my editor.
Another example: preview contents of tmux sessions before switching to it, a pseudo-code command would be like this tmux list-windows | zf --preview "tmux-preview {}" --preview-window-size=60 | xargs -n1 -I{} tmux switch-to {}
.
@kovetskiy thanks for expressing interest!
I've only thought about this feature for a day now, but I'm 95% certain I'll add it. I think I'll target the 0.9.0 release (0.8.0 should be released in about 2 weeks probably) so not too far away. Maybe sooner depending on how much time the remaining 0.8.0 features take.
At the same time, I want to keep zf really simple (I think fzf has way too many options). But I also want to make it useful. I think --preview
and --preview-size
commands are reasonable. Are you aware of any other options that might be needed?
Also, is the --preview-size
a column width or a percentage?
Also, is the --preview-size a column width or a percentage?
I think fzf's way is optimal in this sense, it uses a column width (or a number of rows for horizontal preview) if no %
is specified, and uses percentage otherwise. But I'd personally be happy with the percentage as I often resize my windows and can't really stick to some static numbers.
Thanks!
Thanks for the clarification. I think I will start with a percentage, then if it seems like a fixed width is also needed I'll add that.
I thought about this more and I'm not sure how to best add this to zf's main loop. Currently I keep things very CPU efficient by using blocking reads in the UI. The problem with that is if I wanted to make subprocess calls async (which they should be for a good experience) I would need to make the read calls non-blocking. Otherwise the UI preview would not update unless a key was pressed.
This could be trivially handled by adding a sleep of sorts to the main loop. Or using evented IO. Currently Zig's async implementation is incomplete in the self-hosted compiler, but ideally I would use that for syntax support.
I do want to add this, so I'll keep thinking of solutions.
If I'm understanding it correctly, I think std.io.poll
introduced in 0.11.0 will be a good solution. https://github.com/ziglang/zig/pull/14744
So I will add previews once Zig 0.11.0 is released.
I am curious, will the existence of previewing functionality cause a hit to performance even if the previewing is disabled?
@mizlan there shouldn't be any performance impact of a disabled preview with the way I'm planning on adding preview.
I also have some fuzzy plans to add multithreading to zf so if anything, it will be even more performant in the future!
I just merged some commits that introduces an event loop to zf, so I'll start working on this feature in the next week or so!
Added as part of bb27a917c3513785c6a91f0b1c10002a5029cacc, with additional polish in follow-up commits. Will be in the next release of zf.
Adds --preview
and --preview-width
options
Today I finally came across a use case for a UI preview. I am still not 100% sure if this is needed, but here are my thoughts
A new
--preview
long option that accepts a string representing a command to be run. The command accepts{}
as a substitution for the current selected line. Alternate might be--command
(more general)If
--preview
is not null/empty, then the UI will look like thisIt might also be nice to have a keybind to show/hide the preview (hidden by default?)
Again, I'm not 100% convinced this is needed. Maybe for scripts that require a preview command like this I'll just use fzf or something else.