nix-community/kickstart-nix.nvim

Order of runtime path prevents override of ftplugin

Closed this issue · 8 comments

jaycle commented

I believe that it is expected to be able to disable builtin ftplugin's from running by setting the buffer variable did_ftplugin. See :h ftplugin for more info.

The current implementation of initLua in mkNeovim.nix places nvim/ftplugin at the end of rtp, which breaks this behavior.

# Append nvim and after directories to the runtimepath
+ ''
  vim.opt.rtp:append('${nvimRtp}/nvim')
  vim.opt.rtp:append('${nvimRtp}/after')
'';

I've "fixed" this by moving the ${nvimRtp}/nvim section to the top and making it prepend. This does allow me to disable builtin plugins using b:did_ftplugin, but I'm not totally sure if this is the best way.

mrcjkb commented

🤔 that's very strange. Built-in ftplugins shouldn't be influenced by when a directory containing user ftplugins is added to the runtimepath. Also, those are docs for vim's ftplugin. Neovim's filetype plugin is implemented in lua and has slightly different behaviour.

Which ones are you trying to disable?

The reason I add the nvim directory after init.lua is because there's a bug in neovim that can cause ftplugins to be sourced prematurely: neovim/neovim#19008
This can lead to plugins not picking up their config.

There's also a nix way to disable built-in plugins, by removing them from the neovim derivation: https://github.com/ttak0422/loaded-nvim

jaycle commented

Interesting. So the issue I had, was that a particular ftplugin, namely ocaml.vim was adding some keybindings that overrode some of my defaults. I didn't even know about b:did_ftplugin but even from within neovim, typing :h ftplugin took me to that snippet. I may have linked to the incorrect help doc from vim, but neovim certainly suggests this solution, too.

So, when that didn't work, I got to the source ftplugin.vim and it shows that rtp is walked to source these.

Anyway, maybe an issue for neovim docs. Just explaining how I arrived at the conclusion in case some of that is helpful to this project.

jaycle commented

One other interesting thing I found following your linked issue: neovim/neovim#24147

It seems neovim fixed some ftplugin load issues by ensuring that the runtimepath was respected. So I would think that this project's nvim/ should serve as the replacement for a typical users .config/nvim, which would put it earlier (first?) in rtp. No?

mrcjkb commented

neovim/neovim#24147 is about the order in which ftplugins are sourced, not about the order in which they appear on the rtp.

It shouldn't matter if the nvim directory is added to the rtp before or after init.lua.
You're encountering neovim/neovim#19008 because I forgot to remove

cmd.syntax('on')
cmd.syntax('enable')

from the template repo's init.lua.
Those calls are redundant in neovim (they have been carried over from vim). And it's the cmd.syntax('on') call, which is leading to your ftplugin being sourced prematurely.
I will remove them from this repo.

But as long as that bug is not resolved, I will leave the rtp ordering as is, because it's more likely that someone who is calling syntax on will encounter issues with a ftplugin being sourced prematurely.

jaycle commented

Just to be clear, would you expect that removing these two lines would allow one to disable a builtin ftplugin through the documented b:did_ftplugin?

I still am unable and the source seems very much to suggest that runtime-path plays a role here. RTP for my mac has ~/.config/nvim first thing. It would seem to me that we'd want the spiritual equivalent of nvim from kickstart-nix.

mrcjkb commented

Just to be clear, would you expect that removing these two lines would allow one to disable a builtin ftplugin through the documented b:did_ftplugin?

I still am unable and the source seems very much to suggest that runtime-path plays a role here. RTP for my mac has ~/.config/nvim first thing. It would seem to me that we'd want the spiritual equivalent of nvim from kickstart-nix.

🤔 And that if you prepend instead of append (after init.lua)?
Do you have a config or a concrete example I can use to reproduce this?

It would seem to me that we'd want the spiritual equivalent of nvim from kickstart-nix.

Yes, but if the neovim behaviour is buggy, and I can work around it with nix, I would prefer to have the less buggy behaviour until the buggy behaviour in neovim is fixed.

jaycle commented

and that if you prepend instead of append (after init.lua)
If I prepend, I can disable through b:did_ftplugin.

I am happy to make the change just to my config. There are other ways I can disable it now that i understand how it's working.

As for an example, my config at https://github.com/jaycle/kickstart-nix.nvim should show this behavior. But it's not minimal.

Basically, just open any file.ml and then tap <Leader> which will cause which-key to show the bindings added by https://github.com/neovim/neovim/blob/master/runtime/ftplugin/ocaml.vim

I would expect my ocaml.lua to disable.

I could try to put together something more minimal. But again, I'm totally fine to just handle this on my end. Thanks a bunch for looking!

mrcjkb commented

Just tested it, and changing it from append to prepend seems to be enough to get it working, as long as you don't call syntax on.

At least I'm not seeing the keymaps created by ocaml.vim in which key.

Thanks for the detailed research 😄

  • 🎉1