So, kakoune takes the documentation shown for `:doc` from
`$KAKOUNE_RUNTIME/share/kak/doc`. Unfortunately, it seems
that it will ignore files that are symlinks. This is arguably
a bug in kakoune, we workaround it for now by copying the
content of the docfiles.
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 derivation that includes the plugins simply by doing a
`symlinkJoin` of `kakoune-unwrapped` 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. By default kakoune expects the `autoload` directory to be in
`../share/kak/autoload` relative to the location of the `kak` binary.
We need to set the `KAKOUNE_RUNTIME` to point the symlinked
share/kak for this to work.
Upstream has apparently changed the configuration format and is now
throwing an error when the `encrypt_sse` option is set. According to the
current version of the documentation encryption moved to the
`sse_config` option that (is optional and) offers all the features we do
not use or care about for this test.
We've been providing zlib as a buildInput for some time now but rsync
still builds (& links) it's own copy of zlib unless we disable it
explicitly. This cuts down on compilation time but otherwise shouldn't
have any side effects.
Prior to this change, man pages from Nixpkgs written using the mdoc(7)
macros would start like this:
NC(1) BSD General Commands Manual NC(1)
and end like this:
BSD December 27, 2018 BSD
No matter what operating system they were run on.
It's far more accurate to say "Nixpkgs General Commands Manual", so
with this patch we configure groff to do just that. The variable is
called "operating-system", but I think it makes more sense to say
"Nixpkgs" than "NixOS" or something, because packages from Nixpkgs can
run on lots of operating systems, and the important thing is that the
package is from Nixpkgs.
Apparently, v0.1.4 was released twice. The current version of the build
points to the first edition of v0.1.4, which is no longer attached to
the tag "v0.1.4" on GitHub. Hence currently, downloading fails.
This commit adjusts the hash to appropriately refer to the second
edition of v0.1.4
André Silva