Hi Vadim and thank for your email. Sorry for taking so long to respond, been busy with work, life, etc.
Thursday 01 Jun 2017 02:32:24, Vadim A. Misbakh-Soloviov wrote : > Currently, we have a situation, that there are two Vim's: "old" one (vim8) > and > NeoVim (for those who do not know: a fork of Vim with much and much more > clean > code, many neat features and so on). Vim8 is here to stay and has served us well until now. Calling him "old" is unfair. :) To be honest, I haven't given NeoVim a try yet (should I?). > > Unfortunately, both of them have different runtimedirs: XDG ones for NeoVim > and the ones you know for Vim8, while NeoVim is fully compatible with Vim's > plugins, and epecially with vimscripts (like syntax definitions and ftdetect > scripts). ACK. I have one question though: will this retrocompatibility last forever? > > On the other side, we have a bunch of packages in the portage tree, that have > "vim syntax" support (use-flags, or direct vim-syntax packages), or even vim- > plugins. > All of them goes to `/usr/share/vim/vimfiles`, while correct path for NeoVim > would be `/usr/share/nvim/site` (does not exist at the moment, but nvim > checks > for it). That's good to know. > > So, that situation leads to impossibility to get all of that syntax > definitions > and plugins when user uses NeoVim. > > As I said above, NeoVim supports Vim's plugins/scripts very well (although I > didn't find any evidence of the opposite), so it is possible to fix that > situation by many of "kludge" ways, including: > > - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all the > installed files This sounds like a lot of duplicate work for very little gain. > > - patching NeoVim source to include Vim's runtimedirs (incl. "after" dir), > // NeoVim upstream highly disagree with such way, if any Very appealing. Why is NeoVim upstream against this solution by the way? Truth to be told, we can have it our way and patch NeoVim so that it behaves however we like. > > - patching VIMRUNTIME environment variable, Who would need patching in this case: NeoVim or Vim8? > > - making a wrapper, A good approach as well. Will need a bit of maintainenance. > > - rewrite all the existing ebuilds to take nvim into account and force all > newcomers to also take it, Too much work. > > - symlinking a directory, > // mostly bad way, since opposite plugin compatibility is not garanteed and > users can install nvim-only plugins in the future idea-- > > - making postinst hook to regenerate content of NeoVim's site-directory > (maybe, by symlinking installed vim modules there) Ew. > > or even: > > - making eselect module for user to rule that. > > Although, talking on eselect module, I've two visions of the situation: > a) it can be something like bashcomp module, where users can select which of > installed vim modules they want to "enable" in NeoVim > or (better, imo) way: > b) it can be something like php module, where portage installs all the stuff > in the location neither available to Vim nor NeoVim, and users selects which > modules they enable for either implementation. > > Module can be called something like "eselect-vim" or "eselect-vim-modules" > (?), if any. To be honest, the eselect idea looks very convoluted. Why? Please correct me if I'm wrong but by design, most, of not all, modules can be enabled or disabled via the .vimrc file. It only takes a single line in your personal .vimrc file if you wish a module not to load at runtime. I fail to see the added value of an eselect module for solving a task Vim already handles very well. > > > For now, I have preview of neither of eselect module variants, nor even > patches for another "ways". I'd very like to discuss the situation and find a > better of possible solution first. > Maybe, when (if?) we found such a solution, I'd contribute a PR with it on GH. > > -- > wbr, > mva So here you have it. I'm fine with knocking together a wrapper or patching NeoVim sources. Do you think it's a big deal to put NeoVim modules in the app-vim category? It makes more sense to me to keep everything under the same umbrella. Cheers -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
