Neovim template should not contest Vim namespace in alternatives

[atweiden]

Summary:

The neovim template should not install symlinks contesting the vim namespace.

Reasoning:

1. No other major OS vendor treats Neovim and Vim in this way.

2. In 2022, anyone choosing to open Neovim instead of Vim, or vice versa, is making a very deliberate choice. Because Neovim supports Lua as a first class citizen, while Vim only supports Vimscript as a first class citizen, Neovim’s plugin ecosystem has begun to differ significantly from Vim’s. The Neovim editor is increasingly configured separately from Vim — often in Lua, and with a different selection of plugins.

3. By default, an unconfigured Neovim severely alters the terminal cursor’s appearance in a manner which is difficult to counteract without ending the active terminal session. Accidentally opening an unconfigured Neovim instance upon typing vim into a terminal creates an awful user experience — which is precisely what happens when a user installs Neovim after Vim, due to the neovim template’s use of alternatives.

I’ve been using Vim and Neovim both for a good, long while. To any Neovim fans, I wouldn’t have opened this issue if I didn’t want both programs installed simultaneously. But If I’m typing vim in my terminal, I’m most definitely not expecting Neovim to pop open. Type vim, and “the” Vim should open, or an error message should appear. At present, due to the neovim template’s use of alternatives, when you type vim, nvim pops open instead, and the terminal cursor’s appearance is ruined until you exit the terminal session.

[classabbyamp]

when a user installs neovim after vim[, neovim gets chosen as the vim alternative]

That's just not true, if something installed provides an alternative already, xbps should not change it until you use xbps-alternatives to set it. I tried it myself (output abbreviated):

$ xbps-alternatives -l
...
vi
 - nvi (current)
...
$ xi vim
...
$ xbps-alternatives -l
...
vi
 - nvi (current)
 - vim-common
vim
 - vim (current)
...
$ xi neovim
...
$ xbps-alternatives -l
...
vi
 - nvi (current)
 - vim-common
 - neovim
vim
 - vim (current)
 - neovim
...

Maybe you installed neovim before vim?

[classabbyamp]

the terminal cursor’s appearance is ruined until you exit the terminal session

sounds like an issue with your terminal configuration, or something that should be reported upstream to neovim. I don't have this issue with nvim -u NONE

[classabbyamp]

anyone choosing to open Neovim instead of Vim, or vice versa, is making a very deliberate choice

and they can make that choice by installing either package. Neither one is included in void by default (nvi is, but that's beside the point)

[atweiden]

Maybe it was gvim-huge followed by nvim, or maybe I uninstalled vim to install gvim-huge, which resulted in unexpected an symlink. Regardless, Void is the only distro under the sun where this is even a possibility.

I don't have this issue with nvim -u NONE

Just my 2¢: having to run vim -u NONE — not nvim, of course, because of the symlinks — when neovim realistically never should’ve been symlinked to vim in the first place, is rather obtuse.

and they can make that choice by installing either package

Uninstalling Neovim is also an unacceptable solution for those who wish to use both vim and nvim.

[paper42]

when neovim realistically never should’ve been symlinked to vim in the first place, is rather obtuse.

I agree that this shouldn't have been handled with alternatives, but now we if we wanted to remove yhem, we have a problem.
Consider a situation in which the user has neovim installed (so vim points to nvim), but doesn't have vim installed. They also use the vim command to launch nvim and didn't set up an alias. They also have $EDITOR and other similar variables set to vim.
Now an update comes which removes the alternatives and suddenly the user can not run their editor with the vim command and even if they fix it with a shell alias, every program that uses $EDITOR is broken until it's manually fixed.

I am not saying this is a bad idea, but it's not without problems.

and they can make that choice by installing either package

Uninstalling Neovim is also an unacceptable solution for those who wish to use both vim and nvim.

You can just use the xbps-alternatives command to switch to vim and just have both. If you installed them in the right order - vim, then neovim, you don't even have to touch alternatives.

I see why this is confusing and this is part of the reason I don't think nvim should be a vim alternative. On the other hand, I have never seen too different behavior from nvim and vim ootb without any configuration.

[atweiden]

Now an update comes which removes the alternatives and suddenly the user can not run their editor with the vim command and even if they fix it with a shell alias, every program that uses $EDITOR is broken until it's manually fixed.

Equally bad (or worse): running vim as root and accidentally getting Neovim instead because of symlinks setup by Void and no other distro under the sun.

It’s a predicament either way.

If you’d allow me to hazard a guess, the group of Void users setting EDITOR=vim in a security-critical context and also intending this act to configure Neovim to open instead of actual Vim is a minority. And assuming this minority even exists, they have to know they’re acting lazily or irresponsibly. Which is fine — but I doubt this hypothetical minority of admins would be overly offended by an announcement from the Void crew stating something to the effect of the Neovim package’s symlinks being removed.

Perhaps the symlinks can be deprecated in an announcement, and removed at a pre-determined time in the future?

[classabbyamp]

how is that a footgun? how is getting neovim as root a bad thing? Remember, you have to set the alternative if you have both vim and neovim installed

[atweiden]

Can anyone commenting defend their preference for typing out vim to open nvim, or setting EDITOR=vim to open nvim?

[atweiden]

If nvim can be symlinked to vim, why can’t bash be symlinked to dash?

[paper42]

Can anyone commenting defend their preference for typing out vim to open nvim,

For me, it's shorter and I don't have to remember which machine I am on and whether it has nvim or vim.

or setting EDITOR=vim to open nvim?

That's wrong, I just used it as an example and I can imagine some people having this in their rc/.profile.

[atweiden]

For me, it's shorter and I don't have to remember which machine I am on and whether it has nvim or vim.

But vi is even shorter to type out than vim. Using vi in your case would have the same effect on Void. Would you be happy if nvim were symlinked to vi?

[lemmi]

I have a machine that is also used by others, but I'm in charge and want neovim and therefore have no use to keep vim around. So far this has caused zero issues, actually it solved a couple with some terminal stuff, I don't quite remember. This is debian machine fwiw, so there are other distros that behave that way.

[atweiden]

List of OS vendors symlinking nvim to vim:

• Void
• Debian and derivatives

List of OS vendors not symlinking nvim to vim:

• Arch and derivatives
• Alpine
• Fedora
• Gentoo
• SUSE
• Homebrew/Macports
• Nix/Guix
• FreeBSD and all other BSDs

[Duncaen]

You made a list of linux distributions separating them by having an alternatives system.

What is the problem with setting the alternatives to the state you want as opposed to demanding to remove that feature because you personally don't like it.

[atweiden]

Yesterday, I suggested doing:

# Template file for 'dash'
alternatives="
 sh:sh:/usr/bin/dash
 sh:sh.1:/usr/share/man/man1/dash.1"

# Template file for 'bash'
alternatives="
 sh:sh:/usr/bin/bash
 sh:sh.1:/usr/share/man/man1/bash.1"

# Template file for 'neovim'
alternatives="
  vi:vi:/usr/bin/nvim
  vi:vi.1:/usr/share/man/man1/nvim.1

I’ve updated the PR accordingly, to minimize any confusion.

I simply don’t recognize any level of logical consistency in the way Neovim is allowed to easily override vim on Void systems. There is no logical difference between allowing this and allowing bash to override dash. It’s simply not what most users want or expect, edge cases from Debian aside.

[tibequadorian]

I think the problem is that voids alternative system doesn't have priorities like debians alternative system has. This leads to confusion when vim is installed after neovim was installed and it doesn't automatically choose the one with highest priority (which would be vim).

To solve this, we would need to implement priorities for our alternatives which is too much effort in my opinion.

[Duncaen]

Shouldn't have closed it, but I don't think this would get my approval.

I think the problem is that voids alternative system doesn't have priorities like debians alternative system has. This leads to confusion when vim is installed after neovim was installed and it doesn't automatically choose the one with highest priority (which would be vim).

The alternatives switching just because you install something with a higher priority doesn't sound like a good idea.

There is no logical difference between allowing this and allowing bash to override dash. It’s simply not what most users want or expect, edge cases from Debian aside.

External programs depending on dash being dash and bash being bash is IMHO different from a vim fork being allowed as alternative for vim.

[atweiden]

I’ve prepended [RFC] to the associated PR, to additionally minimize confusion. It seems as though this hypothetical change would be best accompanied with an announcement of a retirement date of the vim symlinks at some point in the future.

I’d like to hear alternative opinions.

Thank you for not closing @Duncaen. That was very considerate of you. I appreciate it.

[tibequadorian]

I think the problem is that voids alternative system doesn't have priorities like debians alternative system has. This leads to confusion when vim is installed after neovim was installed and it doesn't automatically choose the one with highest priority (which would be vim).

The alternatives switching just because you install something with a higher priority doesn't sound like a good idea.

This priorities thing is what debian does at least... Except that I was wrong on this particular case: Debians vim and nvim have the same priorities so it doesn't switch automatically. But on another case like installing openjdk-17-jre after openjdk-11-jre it holds true that debian automatically switches the alternatives because openjdk-17-jre has a greater priority.

[Vaelatern]

I think this is wrong. 👍 for closing.

[atweiden]

Thanks for opining, @Vaelatern.

I noticed your name is listed as the maintainer of Neomutt.

According to Neomutt’s homepage:

NeoMutt is a command line mail reader (or MUA). It’s a fork of Mutt with added features.

This seems quite analagous to the relationship between Neovim and Vim.

However, the Neomutt template doesn’t use alternatives at all.

Why is mutt protected from neomutt symlinks, while vim isn’t protected from nvim?

Bear in mind I’ve proposed continuing to allow nvim to symlink vi — so users who don’t care about the gulf between Vim and Neovim can still blindly install one over the other and just type vi to maintain the same workflow.

[classabbyamp]

is there not a bigger gulf between vi and nvim than vim and nvim?

[paper42]

I agree with @Vaelatern and because there 3 team members agree on this, I am closing this issue.

[Vaelatern]

@atweiden you'll find that neomutt deliberately broke compat and suggested it no longer be the same.

For neomutt, this was the answer.

For neovim it's not.

[atweiden]

@atweiden you'll find that neomutt deliberately broke compat and suggested it no longer be the same.

For neomutt, this was the answer.

For neovim it's not.

Try opening a file with vim, closing it, then opening the same file with nvim (or vice versa). You might be surprised to see an error message pop up:

E824: Incompatible undo file: ....

That’s because Neovim has broken Vim compatibility in several subtle ways for a long time now.

Here’s another example: Vim uses viminfo files, but Neovim uses an incompatible ShaDa file. Hence, when attempting to share the same config between vim and nvim, you have to implement a workaround:

if !has('nvim')
  set viminfofile=$VIMPATH/viminfo
  if filereadable(&viminfofile)
    rviminfo
  endif
else
  if filereadable($XDG_DATA_HOME . '/nvim/shada/main.shada')
    rshada
  endif
endif

Otherwise you’ll get an error on startup.

• Neovim uses subtly different highlight groups in certain cases, e.g. WhiteSpace instead of Vim’s SpecialKey for rendering indentation

• nvim severely alters your terminal cursor by default, whereas vim doesn’t

• Neovim plugins are increasingly written in pure Lua, which is not the case with Vim

Bram Moolenaar has been merging features and bug fixes to upstream Vim at a considerably faster pace than Neovim can integrate them downstream for the last several years consecutively. This isn’t meant to throw any shade on Neovim — it’s good to see so much third party development happening on Neovim in Lua. But they’re divergent software projects in several respects.

There was a limited period of time c. 2016 when Neovim was still fighting to become “Vim” due to perceived inaction on Bram’s part. That didn’t happen, but people who don’t heavily use Vim or Neovim may not be aware of such things.

[Vaelatern]

It so happens that I do heavily use vim. And I recently set my alternative for vim to neovim (want to use a Lua-only plugin).

The decision stands.