* [gentoo-dev] [RFC] NeoVim and vim-syntax @ 2017-05-31 19:32 Vadim A. Misbakh-Soloviov 2017-05-31 20:09 ` Peter Volkov ` (3 more replies) 0 siblings, 4 replies; 18+ messages in thread From: Vadim A. Misbakh-Soloviov @ 2017-05-31 19:32 UTC (permalink / raw To: gentoo-dev; +Cc: vim 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 19:32 [gentoo-dev] [RFC] NeoVim and vim-syntax Vadim A. Misbakh-Soloviov @ 2017-05-31 20:09 ` Peter Volkov 2017-05-31 22:54 ` Ciaran McCreesh ` (2 subsequent siblings) 3 siblings, 0 replies; 18+ messages in thread From: Peter Volkov @ 2017-05-31 20:09 UTC (permalink / raw To: gentoo-dev; +Cc: vim [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 19:32 [gentoo-dev] [RFC] NeoVim and vim-syntax Vadim A. Misbakh-Soloviov 2017-05-31 20:09 ` Peter Volkov @ 2017-05-31 22:54 ` Ciaran McCreesh 2017-06-01 1:21 ` Kent Fredric ` (4 more replies) 2017-06-01 21:56 ` Vadim A. Misbakh-Soloviov 2017-07-23 14:17 ` [gentoo-dev] " Patrice Clement 3 siblings, 5 replies; 18+ messages in thread From: Ciaran McCreesh @ 2017-05-31 22:54 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 22:54 ` Ciaran McCreesh @ 2017-06-01 1:21 ` Kent Fredric 2017-06-01 1:38 ` Daniel Campbell ` (3 subsequent siblings) 4 siblings, 0 replies; 18+ messages in thread From: Kent Fredric @ 2017-06-01 1:21 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 22:54 ` Ciaran McCreesh 2017-06-01 1:21 ` Kent Fredric @ 2017-06-01 1:38 ` Daniel Campbell 2017-06-01 5:00 ` Michał Górny ` (2 subsequent siblings) 4 siblings, 0 replies; 18+ messages in thread From: Daniel Campbell @ 2017-06-01 1:38 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 22:54 ` Ciaran McCreesh 2017-06-01 1:21 ` Kent Fredric 2017-06-01 1:38 ` Daniel Campbell @ 2017-06-01 5:00 ` Michał Górny 2017-06-01 5:49 ` Ciaran McCreesh 2017-06-01 8:42 ` Vadim A. Misbakh-Soloviov 2017-06-01 13:38 ` Walter Dnes 4 siblings, 1 reply; 18+ messages in thread From: Michał Górny @ 2017-06-01 5:00 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-06-01 5:00 ` Michał Górny @ 2017-06-01 5:49 ` Ciaran McCreesh 0 siblings, 0 replies; 18+ messages in thread From: Ciaran McCreesh @ 2017-06-01 5:49 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 22:54 ` Ciaran McCreesh ` (2 preceding siblings ...) 2017-06-01 5:00 ` Michał Górny @ 2017-06-01 8:42 ` Vadim A. Misbakh-Soloviov 2017-06-01 13:38 ` Walter Dnes 4 siblings, 0 replies; 18+ messages in thread From: Vadim A. Misbakh-Soloviov @ 2017-06-01 8:42 UTC (permalink / raw To: gentoo-dev > - 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 22:54 ` Ciaran McCreesh ` (3 preceding siblings ...) 2017-06-01 8:42 ` Vadim A. Misbakh-Soloviov @ 2017-06-01 13:38 ` Walter Dnes 2017-06-01 14:54 ` Ciaran McCreesh 2017-06-02 1:14 ` Kent Fredric 4 siblings, 2 replies; 18+ messages in thread From: Walter Dnes @ 2017-06-01 13:38 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-06-01 13:38 ` Walter Dnes @ 2017-06-01 14:54 ` Ciaran McCreesh 2017-06-02 1:14 ` Kent Fredric 1 sibling, 0 replies; 18+ messages in thread From: Ciaran McCreesh @ 2017-06-01 14:54 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-06-01 13:38 ` Walter Dnes 2017-06-01 14:54 ` Ciaran McCreesh @ 2017-06-02 1:14 ` Kent Fredric 2017-06-02 19:34 ` Walter Dnes 1 sibling, 1 reply; 18+ messages in thread From: Kent Fredric @ 2017-06-02 1:14 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-06-02 1:14 ` Kent Fredric @ 2017-06-02 19:34 ` Walter Dnes 2017-06-02 19:39 ` Ciaran McCreesh 0 siblings, 1 reply; 18+ messages in thread From: Walter Dnes @ 2017-06-02 19:34 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-06-02 19:34 ` Walter Dnes @ 2017-06-02 19:39 ` Ciaran McCreesh 0 siblings, 0 replies; 18+ messages in thread From: Ciaran McCreesh @ 2017-06-02 19:39 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-05-31 19:32 [gentoo-dev] [RFC] NeoVim and vim-syntax Vadim A. Misbakh-Soloviov 2017-05-31 20:09 ` Peter Volkov 2017-05-31 22:54 ` Ciaran McCreesh @ 2017-06-01 21:56 ` Vadim A. Misbakh-Soloviov 2017-06-02 4:59 ` Michał Górny 2017-07-23 14:17 ` [gentoo-dev] " Patrice Clement 3 siblings, 1 reply; 18+ messages in thread From: Vadim A. Misbakh-Soloviov @ 2017-06-01 21:56 UTC (permalink / raw To: gentoo-dev; +Cc: vim 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-06-01 21:56 ` Vadim A. Misbakh-Soloviov @ 2017-06-02 4:59 ` Michał Górny 2017-06-02 7:13 ` Vadim A. Misbakh-Soloviov 0 siblings, 1 reply; 18+ messages in thread From: Michał Górny @ 2017-06-02 4:59 UTC (permalink / raw To: gentoo-dev; +Cc: vim [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] [RFC] NeoVim and vim-syntax 2017-06-02 4:59 ` Michał Górny @ 2017-06-02 7:13 ` Vadim A. Misbakh-Soloviov 0 siblings, 0 replies; 18+ messages in thread From: Vadim A. Misbakh-Soloviov @ 2017-06-02 7:13 UTC (permalink / raw To: gentoo-dev > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [gentoo-dev] Re: [RFC] NeoVim and vim-syntax 2017-05-31 19:32 [gentoo-dev] [RFC] NeoVim and vim-syntax Vadim A. Misbakh-Soloviov ` (2 preceding siblings ...) 2017-06-01 21:56 ` Vadim A. Misbakh-Soloviov @ 2017-07-23 14:17 ` Patrice Clement 2017-07-23 21:39 ` William Hubbs 3 siblings, 1 reply; 18+ messages in thread From: Patrice Clement @ 2017-07-23 14:17 UTC (permalink / raw To: Vadim A. Misbakh-Soloviov; +Cc: gentoo-dev, vim 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-dev] Re: [RFC] NeoVim and vim-syntax 2017-07-23 14:17 ` [gentoo-dev] " Patrice Clement @ 2017-07-23 21:39 ` William Hubbs 0 siblings, 0 replies; 18+ messages in thread From: William Hubbs @ 2017-07-23 21:39 UTC (permalink / raw To: gentoo-dev; +Cc: Vadim A. Misbakh-Soloviov, vim [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-07-23 21:40 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-31 19:32 [gentoo-dev] [RFC] NeoVim and vim-syntax Vadim A. Misbakh-Soloviov 2017-05-31 20:09 ` Peter Volkov 2017-05-31 22:54 ` Ciaran McCreesh 2017-06-01 1:21 ` Kent Fredric 2017-06-01 1:38 ` Daniel Campbell 2017-06-01 5:00 ` Michał Górny 2017-06-01 5:49 ` Ciaran McCreesh 2017-06-01 8:42 ` Vadim A. Misbakh-Soloviov 2017-06-01 13:38 ` Walter Dnes 2017-06-01 14:54 ` Ciaran McCreesh 2017-06-02 1:14 ` Kent Fredric 2017-06-02 19:34 ` Walter Dnes 2017-06-02 19:39 ` Ciaran McCreesh 2017-06-01 21:56 ` Vadim A. Misbakh-Soloviov 2017-06-02 4:59 ` Michał Górny 2017-06-02 7:13 ` Vadim A. Misbakh-Soloviov 2017-07-23 14:17 ` [gentoo-dev] " Patrice Clement 2017-07-23 21:39 ` William Hubbs
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox