1 |
Hi Vadim and thank for your email. |
2 |
|
3 |
Sorry for taking so long to respond, been busy with work, life, etc. |
4 |
|
5 |
Thursday 01 Jun 2017 02:32:24, Vadim A. Misbakh-Soloviov wrote : |
6 |
> Currently, we have a situation, that there are two Vim's: "old" one (vim8) and |
7 |
> NeoVim (for those who do not know: a fork of Vim with much and much more clean |
8 |
> code, many neat features and so on). |
9 |
Vim8 is here to stay and has served us well until now. Calling him "old" is |
10 |
unfair. :) |
11 |
|
12 |
To be honest, I haven't given NeoVim a try yet (should I?). |
13 |
> |
14 |
> Unfortunately, both of them have different runtimedirs: XDG ones for NeoVim |
15 |
> and the ones you know for Vim8, while NeoVim is fully compatible with Vim's |
16 |
> plugins, and epecially with vimscripts (like syntax definitions and ftdetect |
17 |
> scripts). |
18 |
ACK. I have one question though: will this retrocompatibility last forever? |
19 |
|
20 |
> |
21 |
> On the other side, we have a bunch of packages in the portage tree, that have |
22 |
> "vim syntax" support (use-flags, or direct vim-syntax packages), or even vim- |
23 |
> plugins. |
24 |
> All of them goes to `/usr/share/vim/vimfiles`, while correct path for NeoVim |
25 |
> would be `/usr/share/nvim/site` (does not exist at the moment, but nvim checks |
26 |
> for it). |
27 |
That's good to know. |
28 |
> |
29 |
> So, that situation leads to impossibility to get all of that syntax definitions |
30 |
> and plugins when user uses NeoVim. |
31 |
> |
32 |
> As I said above, NeoVim supports Vim's plugins/scripts very well (although I |
33 |
> didn't find any evidence of the opposite), so it is possible to fix that |
34 |
> situation by many of "kludge" ways, including: |
35 |
> |
36 |
> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all the |
37 |
> installed files |
38 |
This sounds like a lot of duplicate work for very little gain. |
39 |
> |
40 |
> - patching NeoVim source to include Vim's runtimedirs (incl. "after" dir), |
41 |
> // NeoVim upstream highly disagree with such way, if any |
42 |
Very appealing. |
43 |
|
44 |
Why is NeoVim upstream against this solution by the way? Truth to be told, we |
45 |
can have it our way and patch NeoVim so that it behaves however we like. |
46 |
> |
47 |
> - patching VIMRUNTIME environment variable, |
48 |
Who would need patching in this case: NeoVim or Vim8? |
49 |
> |
50 |
> - making a wrapper, |
51 |
A good approach as well. Will need a bit of maintainenance. |
52 |
> |
53 |
> - rewrite all the existing ebuilds to take nvim into account and force all |
54 |
> newcomers to also take it, |
55 |
Too much work. |
56 |
> |
57 |
> - symlinking a directory, |
58 |
> // mostly bad way, since opposite plugin compatibility is not garanteed and |
59 |
> users can install nvim-only plugins in the future |
60 |
idea-- |
61 |
> |
62 |
> - making postinst hook to regenerate content of NeoVim's site-directory |
63 |
> (maybe, by symlinking installed vim modules there) |
64 |
Ew. |
65 |
> |
66 |
> or even: |
67 |
> |
68 |
> - making eselect module for user to rule that. |
69 |
> |
70 |
> Although, talking on eselect module, I've two visions of the situation: |
71 |
> a) it can be something like bashcomp module, where users can select which of |
72 |
> installed vim modules they want to "enable" in NeoVim |
73 |
> or (better, imo) way: |
74 |
> b) it can be something like php module, where portage installs all the stuff |
75 |
> in the location neither available to Vim nor NeoVim, and users selects which |
76 |
> modules they enable for either implementation. |
77 |
> |
78 |
> Module can be called something like "eselect-vim" or "eselect-vim-modules" |
79 |
> (?), if any. |
80 |
To be honest, the eselect idea looks very convoluted. Why? |
81 |
|
82 |
Please correct me if I'm wrong but by design, most, of not all, modules can be |
83 |
enabled or disabled via the .vimrc file. It only takes a single line in your |
84 |
personal .vimrc file if you wish a module not to load at runtime. I fail to see |
85 |
the added value of an eselect module for solving a task Vim already handles |
86 |
very well. |
87 |
> |
88 |
> |
89 |
> For now, I have preview of neither of eselect module variants, nor even |
90 |
> patches for another "ways". I'd very like to discuss the situation and find a |
91 |
> better of possible solution first. |
92 |
> Maybe, when (if?) we found such a solution, I'd contribute a PR with it on GH. |
93 |
> |
94 |
> -- |
95 |
> wbr, |
96 |
> mva |
97 |
|
98 |
So here you have it. I'm fine with knocking together a wrapper or patching |
99 |
NeoVim sources. Do you think it's a big deal to put NeoVim modules in the |
100 |
app-vim category? It makes more sense to me to keep everything under the same |
101 |
umbrella. |
102 |
|
103 |
Cheers |
104 |
-- |
105 |
Patrice Clement |
106 |
Gentoo Linux developer |
107 |
http://www.gentoo.org |