guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Neovim plugin/addon packaging


From: Jack Hill
Subject: Re: Neovim plugin/addon packaging
Date: Sat, 1 May 2021 16:25:18 -0400 (EDT)
User-agent: Alpine 2.21 (DEB 202 2017-01-01)

Thanks for your reply.

On Fri, 30 Apr 2021, Efraim Flashner wrote:

On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote:
Greetings Guix,

I'd like to improve the experience of installing Neovim plugins/add-ons with
Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so
nvim (the Neovim executable name) will be able to find plugins installed by
guix at …/share/nvim/site.

I guess my first question is does it work? I think I first tried
something similar for vim with 'share/vim/vimfiles' but it didn't
actually work for vim.

Yes, it does work! I tested it with neovim-syntastic and a local neovim-fugitive package both with a guix environment and manually manipulated environment variables.

A difference between Neovim and Vim is that Neovim supports XDG_DATA_DIRS (and XDG_CONFIG_DIRS) as real search paths while the environment variables for Vim are single directories (compare `:help runtimepath` in the two editors).

Currently, we only have one such package, neovim-syntastic. I'd like to add
more. Many plugins are compatible with both vim and nvim. However, they
search for plugins at different paths. Therefore, the vim-syntastic and
neovim-syntastic packages, which use the copy-build-system, differ only in
the destination directories of the install-plan (and changing "Vim" to
"Neovim" in the description).

My initial inclination is to remove the duplication of maintaining two
install-plans (and other arguments) by creating a procedure that would take
as input a Vim package that uses copy-build-system and output a Neovim
package with the install-plan re-written.

Perhaps that solution would be overwrought. How would you recommend handling
this situation?

My first idea would be to have the one package install the files into
both directories and combine them, but I feel like it falls apart when
it comes to searching for vim/neovim plugins and naming. One package
with two names? Call it vim-neovim-syntastic?

If vim/neovim move more apart and actually need separate plugins in the
future then I guess it would make more sense to have two actual packages
that can be installed by name (vim-foo and neovim-foo).

A combined package is an interesting suggestion. However, I share the concern about searching for packages. Having packages that are compatible with both editors use one naming scheme and ones that are compatible with only one use a different naming scheme seems like a implementation detail that would be better not to expose to me.

I drew inspiration for creating the Neovim package variants with a procedure from the package-for-python2 and sbcl-package->ecl-package. Of course those procedures have build system support and aren't depending on a common usage pattern of copy-build-system.

Is it time a a vim-build-system? Perhaps not, but I'm still not sure what the right way forward is.

Best,
Jack

reply via email to

[Prev in Thread] Current Thread [Next in Thread]