You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fish supports lazy loading ("automatic activation") of functions, but virtualfish isn't compatible with it. Supporting it is a matter of creating a vf.fish in the vendor_functions.d directory that has the vf function's definition and nothing else, and another vf.fish in the vendor_completions.d directory which has all of vf's tab-completion code.
This would be simple enough but for virtualfish's plugin-based structure, which might be tricky to shoe-horn into the structure required by fish. What I'm thinking at the moment is that the vf command lazily loads the appropriate plugin before calling it, and that each plugin provides a separate plugin_completion.fish, and all of the ones for the active plugins get concatenated together as part of the install process. Plugins that need things like event handlers could also provide a plugin_init.fish that gets concatenated into an init.d script (see #111).
The other option is just ditching the plugin structure altogether; I'm quite fond of it, but there's only a few plugins, so it might not be worth it.
On that note, I'm 50/50 on whether this whole thing is worth the effort or not; auto-activation users will get at least parts of vf loaded every time they cd anyway, and after we implement #111, virtualfish's shell startup overhead should reduce anyway.
The text was updated successfully, but these errors were encountered:
Fish supports lazy loading ("automatic activation") of functions, but virtualfish isn't compatible with it. Supporting it is a matter of creating a
vf.fish
in thevendor_functions.d
directory that has thevf
function's definition and nothing else, and anothervf.fish
in thevendor_completions.d
directory which has all ofvf
's tab-completion code.This would be simple enough but for virtualfish's plugin-based structure, which might be tricky to shoe-horn into the structure required by
fish
. What I'm thinking at the moment is that thevf
command lazily loads the appropriate plugin before calling it, and that each plugin provides a separateplugin_completion.fish
, and all of the ones for the active plugins get concatenated together as part of the install process. Plugins that need things like event handlers could also provide aplugin_init.fish
that gets concatenated into aninit.d
script (see #111).The other option is just ditching the plugin structure altogether; I'm quite fond of it, but there's only a few plugins, so it might not be worth it.
On that note, I'm 50/50 on whether this whole thing is worth the effort or not; auto-activation users will get at least parts of
vf
loaded every time theycd
anyway, and after we implement #111, virtualfish's shell startup overhead should reduce anyway.The text was updated successfully, but these errors were encountered: