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.
Fish supports lazy loading ("automatic activation") of functions, but virtualfish isn't compatible with it. Supporting it is a matter of creating a
vf.fishin thevendor_functions.ddirectory that has thevffunction's definition and nothing else, and anothervf.fishin thevendor_completions.ddirectory 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 thevfcommand 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.fishthat gets concatenated into aninit.dscript (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
vfloaded every time theycdanyway, and after we implement #111, virtualfish's shell startup overhead should reduce anyway.