zf

zf copied to clipboard

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 this

>                                                                                             5/5
main                                               │               command output
missing-return-type                                │
nathan-pilot                                       │
php-8.1-upgrade                                    │
php-8.1-upgrade-whitespace                         │

It 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.

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!