Caching fzf --preview output #29
dimo414
started this conversation in
Show and tell
Replies: 2 comments 2 replies
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Interesting one. I'm building my own alternative to fzf called sunbeam, I'll probably include bkt in some examples. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I often use
bktto speed upfzf's--previewbehavior by caching the output of each preview invocation.Of course you can just prefix the command you want to run with
bkt, like:This works, and using a long TTL and short stale duration means - once cached - the preview will be refreshed in the background as the user navigates the
fzfselector. But it'd be great if the user didn't have to wait for each preview the first time they scroll over a given element - ideally the cache would be warm(er) so the user can dive right in. Here's a demo directory-picker script that warmsbkt's cache before launchingfzfso the previews render more responsively. Give it a try!Notes:
previewfunction demoed here is pretty zippy, especially for non-git directories, so try adding asleep 2line to it to observe how a slower command would run.fzf- it's super convenient for defining complex behavior that doesn't merit being pulled into a standalone script. This works even withoutbkt, you could just do--preview=preview {}'if you wanted sincefzfdispatches the preview command through your$SHELLby default.BKT_SCOPE=dir-picker. This would allow separate calls to the script to share the same cache, but this might lead to unexpectedly stale data showing up. By using a dynamic scope you ensure all previews are at least as fresh as when the picker launched, even if they subsequently get stale.bkt's--warmin order to warm the cache more gradually. This might not be the best tradeoff, depending on the specific use case. You could tweak it to warm a few directories at a time to make faster progress or process the options in a different order if you can anticipate which options a user is likely to care about.bkt(currently) doesn't stream output as the command is executing, whichfzfsupports. It may be better not to cache commands that are slow but update frequently while running.Beta Was this translation helpful? Give feedback.
All reactions