[gentoo-dev] [RFC] NeoVim and vim-syntax

[gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

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).

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).

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).

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

- patching NeoVim source to include Vim's runtimedirs (incl. "after" dir),
// NeoVim upstream highly disagree with such way, if any

- patching VIMRUNTIME environment variable,

- making a wrapper,

- rewrite all the existing ebuilds to take nvim into account and force all 
newcomers to also take it,

- symlinking a directory,
// mostly bad way, since opposite plugin compatibility is not garanteed and 
users can install nvim-only plugins in the future

- making postinst hook to regenerate content of NeoVim's site-directory 
(maybe, by symlinking installed vim modules there)

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.


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

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Hi.

On Wed, May 31, 2017 at 10:32 PM, Vadim A. Misbakh-Soloviov <gentoo@mva.name>
wrote:
> Currently, we have a situation, that there are two Vim's: "old" one
(vim8) and
> NeoVim... Unfortunately, both of them have different runtimedirs...
>
> ... 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:
>
> - patching NeoVim source to include Vim's runtimedirs (incl. "after" dir),
> // NeoVim upstream highly disagree with such way, if any

But what is the reasoning for upstream from this way? If NeoVim supports
vim plugins but not vice versa this looks as a very logical step.

--
Peter.

[-- Attachment #2: Type: text/html, Size: 933 bytes --]

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Ciaran McCreesh]

On Thu, 01 Jun 2017 02:32:24 +0700
"Vadim A. Misbakh-Soloviov" <gentoo@mva.name> wrote:
> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
> the installed files
> 
> - patching NeoVim source to include Vim's runtimedirs (incl. "after"
> dir), // NeoVim upstream highly disagree with such way, if any
> 
> - patching VIMRUNTIME environment variable,
> 
> - making a wrapper,
> 
> - rewrite all the existing ebuilds to take nvim into account and
> force all newcomers to also take it,
> 
> - symlinking a directory,
> // mostly bad way, since opposite plugin compatibility is not
> garanteed and users can install nvim-only plugins in the future
> 
> - making postinst hook to regenerate content of NeoVim's
> site-directory (maybe, by symlinking installed vim modules there)
> 
> or even:
> 
> - making eselect module for user to rule that.

- Have a separate anyvimishthing directory, and make both vim and
neovim look there, and only make plugins that have been tested to work
with both install to that directory.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 286 bytes --]

On Wed, 31 May 2017 23:54:59 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.

+1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1761 bytes --]

On 05/31/2017 03:54 PM, Ciaran McCreesh wrote:
> On Thu, 01 Jun 2017 02:32:24 +0700
> "Vadim A. Misbakh-Soloviov" <gentoo@mva.name> wrote:
>> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
>> the installed files
>>
>> - patching NeoVim source to include Vim's runtimedirs (incl. "after"
>> dir), // NeoVim upstream highly disagree with such way, if any
>>
>> - patching VIMRUNTIME environment variable,
>>
>> - making a wrapper,
>>
>> - rewrite all the existing ebuilds to take nvim into account and
>> force all newcomers to also take it,
>>
>> - symlinking a directory,
>> // mostly bad way, since opposite plugin compatibility is not
>> garanteed and users can install nvim-only plugins in the future
>>
>> - making postinst hook to regenerate content of NeoVim's
>> site-directory (maybe, by symlinking installed vim modules there)
>>
>> or even:
>>
>> - making eselect module for user to rule that.
> 
> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.
> 

+1, though it's still important to keep nvim- and vim-specific dirs.

A third, common dir cuts down on the work that other solutions would
need. It would also give users a way to check which plugins will work
with 'the other one' too and can use that to decide whether they want to
make the switch. This information can probably be gleaned on their own
with some detective work on the Web, but choosing this path gives the
accidental feature for free.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On śro, 2017-05-31 at 23:54 +0100, Ciaran McCreesh wrote:
> On Thu, 01 Jun 2017 02:32:24 +0700
> "Vadim A. Misbakh-Soloviov" <gentoo@mva.name> wrote:
> > - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
> > the installed files
> > 
> > - patching NeoVim source to include Vim's runtimedirs (incl. "after"
> > dir), // NeoVim upstream highly disagree with such way, if any
> > 
> > - patching VIMRUNTIME environment variable,
> > 
> > - making a wrapper,
> > 
> > - rewrite all the existing ebuilds to take nvim into account and
> > force all newcomers to also take it,
> > 
> > - symlinking a directory,
> > // mostly bad way, since opposite plugin compatibility is not
> > garanteed and users can install nvim-only plugins in the future
> > 
> > - making postinst hook to regenerate content of NeoVim's
> > site-directory (maybe, by symlinking installed vim modules there)
> > 
> > or even:
> > 
> > - making eselect module for user to rule that.
> 
> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.
> 

...and then vimthreesome for things that work with three vim
implementations?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Ciaran McCreesh]

On Thu, 01 Jun 2017 07:00:30 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > - Have a separate anyvimishthing directory, and make both vim and
> > neovim look there, and only make plugins that have been tested to
> > work with both install to that directory.
> 
> ...and then vimthreesome for things that work with three vim
> implementations?

If that ever happens, which is fairly unlikely, then revisit the
problem then, rather than adding unnecessary complexity now just in
case.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.

Actually it is almost the thing I described as "second" eselect variant.
Although, you suggest for gentoo devs to check modules work (and we're all 
know that it can take eternity), while I suggest to give users a tool to rule 
that on their own.

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Walter Dnes]

On Wed, May 31, 2017 at 11:54:59PM +0100, Ciaran McCreesh wrote

> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.

  As mentioned elsewhere, what happens when two or three other people
do their own forks?  Plugin 1 works with vim A and B but not C or D.
Plugin 2 works with vim A and C and D but not B.  The number of
directories could potentially be 2^N where N is the number of forks.
And who's going to do the necessary testing across multiple versions?
And remember that each minor version bump of any of the forks could
render another fork's plugin incompatable.  This is a classic "moving
target".  The only way that works is to have each fork look after their
own copies of plugins.

  This reminds me of Firefox and Pale Moon, except that browser plugins
are user-installed.  After the initial fork from Firefox, plugins were
mostly compatable amongst the two browsers.  Over time, as the code
diverged, fewer plugins remained compatable (not talking about Firefox's
upcoming deprecation of XUL).  E.g. Pale Moon now has a forked version of
Ad Block Plus to ensure that it works on Pale Moon..

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Ciaran McCreesh]

On Thu, 1 Jun 2017 09:38:01 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
> On Wed, May 31, 2017 at 11:54:59PM +0100, Ciaran McCreesh wrote
> > - Have a separate anyvimishthing directory, and make both vim and
> > neovim look there, and only make plugins that have been tested to
> > work with both install to that directory.  
> 
>   As mentioned elsewhere, what happens when two or three other people
> do their own forks?

Nothing, unless those forks obtain large user bases, and then the issue
gets revisited. This is unlikely to happen.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

1) Dear Vim Team, can we hear your opinions?

2) I'd like to know if discussion participants really differs my eselect-php-
like suggestion (where all scripts goes to another directory, controlled by 
neither of vims, and then users should/can manually dis-/enable modules for 
each of vim they want) from Ciaran's suggestion of making a directory common 
for all vims, patch all the vims, and force *developers* to check modules and 
put them there only after check modules under both (currently) vims (as side 
effect leave neovim users without modules until developers finaly finish that 
work).

And what point they (participants) really supports?

3) Again, dear Vim Team, please come here, and take a part in the discussion.

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

On Thu, 1 Jun 2017 09:38:01 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

>   As mentioned elsewhere, what happens when two or three other people
> do their own forks?  Plugin 1 works with vim A and B but not C or D.
> Plugin 2 works with vim A and C and D but not B.  The number of
> directories could potentially be 2^N where N is the number of forks.
> And who's going to do the necessary testing across multiple versions?
> And remember that each minor version bump of any of the forks could
> render another fork's plugin incompatable.  This is a classic "moving
> target".  The only way that works is to have each fork look after their
> own copies of plugins.

If and when that happens:

1. Packages that are available on only one vim still install to the one dir
2. Packages that are available on >1 install to a common dir
3. Vim runtimes *don't* all use the common dir, but only their own
4. Packages that support multiple vims get symlinked into their respective
   vim paths at install time.

"4" could be done in a PYTHON_TARGETS sort of way, but its obvious to see why
I'd say "lets not do that unless we absolutely have to".

"4" could alternatively be implemented by creating a meta-file that enumerates
a list of source files to symlink, and the list of vim implementations that are
known to be supported by it, and then a tool can fix up the difference in pkg_postinst
or on-demand.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On pią, 2017-06-02 at 04:56 +0700, Vadim A. Misbakh-Soloviov wrote:
> 1) Dear Vim Team, can we hear your opinions?
> 
> 2) I'd like to know if discussion participants really differs my eselect-php-
> like suggestion (where all scripts goes to another directory, controlled by 
> neither of vims, and then users should/can manually dis-/enable modules for 
> each of vim they want) from Ciaran's suggestion of making a directory common 
> for all vims, patch all the vims, and force *developers* to check modules and 
> put them there only after check modules under both (currently) vims (as side 
> effect leave neovim users without modules until developers finaly finish that 
> work).
> 
> And what point they (participants) really supports?

Just FYI, I'm strongly against eselect modules (and any user code) that
writes into /usr (except for /usr/local). This directory should be
reserved for package manager control, and files in it should be
registered in vdb.

> 
> 3) Again, dear Vim Team, please come here, and take a part in the discussion.
> 

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

> strongly against eselect modules (and any user code) that
> writes into /usr (except for /usr/local)

Well, NeoVim, at least, have support for site-dir in /usr/local out of the 
box. I guess, Vim8 will need a bit of patching for that.

Although, I'm, in opposite, dislike (very little, tho) /usr/local, since it 
makes me feel like FreeBSD'er.

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Walter Dnes]

On Fri, Jun 02, 2017 at 01:14:31PM +1200, Kent Fredric wrote
> On Thu, 1 Jun 2017 09:38:01 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> 
> >   As mentioned elsewhere, what happens when two or three other
> > people do their own forks?  Plugin 1 works with vim A and B but
> > not C or D.  Plugin 2 works with vim A and C and D but not B.  The
> > number of directories could potentially be 2^N where N is the number
> > of forks.  And who's going to do the necessary testing across
> > multiple versions?  And remember that each minor version bump of any
> > of the forks could render another fork's plugin incompatable.  This
> > is a classic "moving target".  The only way that works is to have
> > each fork look after their own copies of plugins.
> 
> If and when that happens:

  It already has happened.  Compare /usr/portage/app-editors against
http://texteditors.org/cgi-bin/wiki.pl?ViFamily  Portage has...

* elvis
* levee
* nvi
* vi
* vim
* vis

...not to mention neovim, which doesn't show up on texteditors.org.

> "4" could alternatively be implemented by creating a meta-file that
> enumerates a list of source files to symlink, and the list of vim
> implementations that are known to be supported by it, and then a
> tool can fix up the difference in pkg_postinst or on-demand.

  This would require a multi-dimensional array of approx 7 packages
(today) versus however many ebuilds are currently in Portage for each
editor.  Do I see any volunteers for compatibility testing for all
current and future VI-family editors and plugins on all current and
future ebuilds on all arches (small and large endian) and various USE
flags?  And what happens when 2 or more editors make different plugins
with the same file names?  This is not a "software ecosystem", and the
various upstreams are not obligated to co-operate with each other.
Indeed, the reason for a fork may be bad blood between developers in the
first place.

  A lot of complexity to save a few kbytes on a multi-terabyte hard
drive (even a 128 gig SSD) does not make sense.  And it may actually
use more space in the long run.  If I have only vim, do I really want
everybody else's plugins installed?  No.  But if I do switch over to
another VI-family editor, or install one simultaneously, how does a
separate "plugins package" know which plugins to install?  And if I
uninstall one editor, how does the "plugins package" know which plugins
to uninstall?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Ciaran McCreesh]

On Fri, 2 Jun 2017 15:34:19 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
> On Fri, Jun 02, 2017 at 01:14:31PM +1200, Kent Fredric wrote
> > On Thu, 1 Jun 2017 09:38:01 -0400
> > "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> >   
> > >   As mentioned elsewhere, what happens when two or three other
> > > people do their own forks?  Plugin 1 works with vim A and B but
> > > not C or D.  Plugin 2 works with vim A and C and D but not B.  The
> > > number of directories could potentially be 2^N where N is the
> > > number of forks.  And who's going to do the necessary testing
> > > across multiple versions?  And remember that each minor version
> > > bump of any of the forks could render another fork's plugin
> > > incompatable.  This is a classic "moving target".  The only way
> > > that works is to have each fork look after their own copies of
> > > plugins.  
> > 
> > If and when that happens:  
> 
>   It already has happened.  Compare /usr/portage/app-editors against
> http://texteditors.org/cgi-bin/wiki.pl?ViFamily  Portage has...
> 
> * elvis
> * levee
> * nvi
> * vi
> * vim
> * vis
> 
> ...not to mention neovim, which doesn't show up on texteditors.org.

And none of the rest of those are Vim compatible, or support Vim's
scripting language. NeoVim is the only one that does, and only because
it's effectively a fork.

>   This would require a multi-dimensional array of approx 7 packages
> (today) versus however many ebuilds are currently in Portage for each
> editor.  Do I see any volunteers for compatibility testing for all
> current and future VI-family editors and plugins on all current and
> future ebuilds on all arches (small and large endian) and various USE
> flags?

You appear to be confusing vi and vim.

-- 
Ciaran McCreesh

[gentoo-dev] Re: [RFC] NeoVim and vim-syntax

[Patrice Clement]

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

Re: [gentoo-dev] Re: [RFC] NeoVim and vim-syntax

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On Sun, Jul 23, 2017 at 04:17:10PM +0200, Patrice Clement wrote:
> 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?
 
If we aren't sure that compatibility will go both ways forever, e.g.
neovim will always support vim8 files and vim8 will always support
neovim files,  I do not recommend making them both use the same runtime
directory. I imagine upstream neovim set a different runtime directory
so that if they diverge things won't break, and I wouldn't try to merge
the runtime directories.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]