[ISSUE] Neovim template should not contest Vim namespace in `alternatives`

[ISSUE] Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New issue by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164

Description:
**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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068533085

Comment:
> 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, xbps should not change it until you use `xbps-alternatives` to set it. I tried it myself (output abbreviated):
```sh
$ 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
...
```

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068534577

Comment:
> 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`

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068537300

Comment:
> 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)

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068533085

Comment:
> 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):
```sh
$ 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
...
```

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068533085

Comment:
> 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):
```sh
$ 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`?

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068564628

Comment:
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`.

Re: Neovim template should not contest Vim namespace in `alternatives`

[paper42]

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

New comment by paper42 on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068583988

Comment:
> 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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068642939

Comment:
> 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?

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068666898

Comment:
how is that a footgun? how is getting neovim as root a bad thing?

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068666898

Comment:
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

Re: Neovim template should not contest Vim namespace in `alternatives`

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068668841

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

What is the reason for that, alternatives are alternatives, they don't have to be 100% the same.
There is nothing wrong with having nvim as vim alternative, other then its to your disliking, but easily fixed using the alternatives.
I don't see any reason to change anything here.

Re: Neovim template should not contest Vim namespace in `alternatives`

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068668841

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

What is the reason for that, alternatives are alternatives, they don't have to be 100% the same.
There is nothing wrong with having nvim as vim alternative, other then its to your disliking, but easily fixed using the alternatives.
I don't see any reason to change anything here.

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068743097

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

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068765755

Comment:
If `nvim` can be symlinked to `vim`, [why can’t `bash` be symlinked to `dash`](https://github.com/void-linux/void-packages/pull/36165#issuecomment-1068754834)?

Re: Neovim template should not contest Vim namespace in `alternatives`

[paper42]

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

New comment by paper42 on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068905631

Comment:
> 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 <shell>rc/.profile. 

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1068932583

Comment:
> 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`?

Re: Neovim template should not contest Vim namespace in `alternatives`

[lemmi]

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

New comment by lemmi on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069673766

Comment:
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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069778232

Comment:
List of OS vendors symlinking `nvim` to `vim`:

- Void
- Debian and derivatives

List of OS vendors not symlinking `nvim` to `vim`:

- Arch
- Alpine
- Fedora
- Gentoo
- SUSE
- Homebrew/Macports
- ...

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069778232

Comment:
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

Re: Neovim template should not contest Vim namespace in `alternatives`

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069790268

Comment:
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 demeaning the remove that feature because you personally don't like it.

Re: Neovim template should not contest Vim namespace in `alternatives`

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069790268

Comment:
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 the remove that feature because you personally don't like it.

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069799912

Comment:
Yesterday, I suggested [doing](https://github.com/void-linux/void-packages/pull/36165#issuecomment-1068754834):

```bash
# 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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069800839

Comment:
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.

Re: [ISSUE] [CLOSED] Neovim template should not contest Vim namespace in `alternatives`

[Duncaen]

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

Closed issue by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164

Description:
**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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069800839

Comment:
I think the problem is that voids alternative system doesn't have priorities like [debians alternative system](https://wiki.debian.org/DebianAlternatives#Intents_and_priorities) 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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069790268

Comment:
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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069817609

Comment:
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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1069824155

Comment:
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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1072350481

Comment:
> > 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 bigger priority.

Re: Neovim template should not contest Vim namespace in `alternatives`

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1072350485

Comment:
> > 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 bigger priority.

Re: Neovim template should not contest Vim namespace in `alternatives`

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1072350485

Comment:
> > 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 bigger priority.

Re: Neovim template should not contest Vim namespace in `alternatives`

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1072350481

Comment:
> > 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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[Vaelatern]

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

New comment by Vaelatern on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1079989646

Comment:
I think this is wrong. :+1: for closing.

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1080009878

Comment:
Thanks for opining, @Vaelatern.

I noticed your name is listed as [the maintainer of Neomutt](https://github.com/void-linux/void-packages/blob/a62f4724bb2f99f9ca8e1a66e8eee76bd3ffd1ce/srcpkgs/neomutt/template#L19).

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](https://github.com/void-linux/void-packages/pull/36165) 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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[classabbyamp]

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

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1080013216

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

Re: Neovim template should not contest Vim namespace in `alternatives`

[Vaelatern]

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

New comment by Vaelatern on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1080027435

Comment:
@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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[atweiden]

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

New comment by atweiden on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1080035784

Comment:
> @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](http://vimdoc.sourceforge.net/htmldoc/starting.html#viminfo) files, but Neovim uses an incompatible [ShaDa](https://neovim.io/doc/user/starting.html#shada-file) file. Hence, when attempting to share the same config between `vim` and `nvim`, you have to implement a workaround:

```vim
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.

Re: Neovim template should not contest Vim namespace in `alternatives`

[Vaelatern]

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

New comment by Vaelatern on void-packages repository

https://github.com/void-linux/void-packages/issues/36164#issuecomment-1080079551

Comment:
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.