For quite some time now, @almr and I have been working on a new plugin manager called kak-bundle, as an alternative to plug.kak:
This plugin manager focuses primarily on load time, while simultaneously offering a large subset of the functionality offered by plug.kak. In our testing (well, mostly @almr’s testing ), kak-bundle seems to load about 20% faster than an equivalent plug.kak configuration using the plug-chain command.
Again, as mentioned above, a huge thanks to @almr for his work on this plugin. He has a lot more time to work on this sort of thing than I do, so while we may have collaborated a fair bit on the design of this plugin, frankly most of the actual implementation work has been him.
@almr also created a plug.kak compatibility layer for kak-bundle, which should help those transferring from plug.kak to kak-bundle:
It is really great to see other plugin managers for Kakoune!
I don’t have a lot of time these days to spend on plugin development, so I’m more or less in a maintenance mode right now, trying to fix bugs if reported by users but don’t have time to improve performance, and @almr was a very huge help in plug.kak recently in this regard, implementing plug-chain and optimizing a lot of stuff, so huge thanks to him!
I have a good feeling about Kakoune plugins lately, seems like a lot of things appeared in a much lighter form. I often tend to overengineer things, so when I see a plugin that does something similar to one of the mine plugins, I’m always glad that someone made a more simple thing that will be easier to maintain than my code
Unfortunately, I do not have performance metrics to compare to @alexherbo2’s solution (which was a huge source of inspiration for this plugin, actually). However, you can set the bundle_path option to a location within the autoload directory for a similar effect with kak-bundle.
Really happy to see more plugin manager flourish, it comforts me in the idea that Kakoune core should only provide building blocks and leave the community explore the design space.
An update in case anyone still cares. kak-bundle now has improved handling of post-install hooks - the bundle command now accepts an optional second parameter indicating shell code to execute after the install is complete. For example, for kak-lsp:
@jdugan6240 I find this quite useful. Some of my plugins require pre-processing of the source; as it stands, the best solution I have is to pre-process source code every time the plugin is loaded (which increases startup time).
I’ve thought about using git hooks to re-preprocess the source as needed (and cache results), but I’m not sure they can cover every pull / merge scenario. Another way is to cache results and check timestamps, but AFAICT this is not portable (shell -ot “older than” isn’t available on FreeBSD sh, plus filesystem timestamps get clobbered in many circumstances).
The only problem is portability between plugin managers. @andreyorst does plug have anything similar?
Thanks for checking it out! I’m actually testing a rewrite of kak-bundle with a simpler design that further improves load time (I think it’s pretty close to optimal now), so if you want to check out the big-rewrite branch, I’d appreciate any feedback on it. It seems to work well for my purposes, but there’s likely an edge case I missed.
As for converging towards one plugin manager, I’m not sure that’s necessary. Since plug.kak is no longer being maintained, the two currently existing plugin managers, kak-bundle and cork.kak, fulfill different niches, with cork.kak offering the ability to easily update plugins outside of Kakoune (as part of your system upgrade routine, for example), at the cost of a slightly limited set of capabilities, and kak-bundle offering a larger feature set at the cost of not being as straightforward to use outside of Kakoune.
), 