Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
kakoune: rework plugin support #91792
Motivation for this change
The previous implementation of plugin-support for the kakoune derivation
The idiomatic way of loading plugins is ensuring they end up installed
For this to work, we need to fix two issues:
The previous implementation of plugin-support for the kakoune derivation was based on generating, at build time, a `plugins.kak` file that would source all .kak files in the list of plugins, and wrap the `kak` binary in a script that would add some command-line arguments so that this file gets loaded on start-up. The main problem with this approach is that the plugins' code get executed *after* the user's configuration file is loaded, so effectively one cannot automatically activate/configure these plugins. The idiomatic way of loading plugins is ensuring they end up installed somwhere under `share/kak/autoload`. Because plugins are already being packaged to have their code in `share/kak/autoload/plugins/<name-of-plugin>`, we can obtain a `kakoune-with-plugins` derivation simply by doing a `symlinkJoin` of `kakoune` and all the requested plugins. For this to work, we need to fix two issues: 1. By default, kakoune makes `share/kak/autoload` a symbolic link to `share/kak/rc`, which contains all builtin definitions. We need to patch this to put the symlink under `share/kak/autoload/rc`, so that the join works. 2. kakoune actually expects the `autoload` directory to be in `../share/kak/autoload` relative to the location of the `kak` binary (and this can't currently be overriden, say, with environment variables), so we can't rely on a symlink for the `kak` binary and need to copy it instead.
eraserhd left a comment
I think I (the original author of the plugin support being changed here) like this approach.
Renaming the packages will break existing users.
Thanks for the feedback, @eraserhd!
I'm not sure what is the convention for naming packages in nixpkgs, tbh. My understanding was that the
The point about backwards compatibility is a very good one. If we were to go with