[-- Attachment #1: Type: text/plain, Size: 1088 bytes --] 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. 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? [0] https://issues.guix.gnu.org/48112 Best, Jack
[-- Attachment #1: Type: text/plain, Size: 2053 bytes --] 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. > 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). > [0] https://issues.guix.gnu.org/48112 > > Best, > Jack -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2968 bytes --] 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
[-- Attachment #1: Type: text/plain, Size: 3647 bytes --] On Sat, May 01, 2021 at 04:25:18PM -0400, Jack Hill wrote: > 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. ng0/nikita thought about it a few years ago but I think the copy-build-system works well enough. I know for vim we need a vim profile hook to create the documentation, does neovim need something like that too? -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On Sun, 2 May 2021, Efraim Flashner wrote:
> ng0/nikita thought about it a few years ago but I think the
> copy-build-system works well enough. I know for vim we need a vim
> profile hook to create the documentation, does neovim need something
> like that too?
I'm not sure and will need to investigate. With the XDG_DATA_DIRS search
path, if I install neovim and neovim-syntastic into the same environment,
I am able to see references to the syntastic documentation in the main
help index, but trying to navigate to them results in a 'E149: Sorry, no
help for syntastic-checkers.txt' error, so clearly something is not quite
right.
Best,
Jack
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --] On Mon, May 03, 2021 at 12:46:30AM -0400, Jack Hill wrote: > On Sun, 2 May 2021, Efraim Flashner wrote: > > > ng0/nikita thought about it a few years ago but I think the > > copy-build-system works well enough. I know for vim we need a vim > > profile hook to create the documentation, does neovim need something > > like that too? > > I'm not sure and will need to investigate. With the XDG_DATA_DIRS search > path, if I install neovim and neovim-syntastic into the same environment, I > am able to see references to the syntastic documentation in the main help > index, but trying to navigate to them results in a 'E149: Sorry, no help for > syntastic-checkers.txt' error, so clearly something is not quite right. > That's always something we can fix later. It's also not more broken than it is now. -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]