I still didn't understand how renaming vi to vim-nox can solve the issue (when not using the patch).

I don't get it as well. Our vi is vim when you don't set it to nocompatible. And between vi and vim in our repos there are quite some more differences than X dependency. The featureset is different and the scripting languages supported are different etc. Our vi is because we need a decent editor in the core/base repo to edit config files at install time it would be a waste to build and extra little vi package that would then conflict with vim because of the runtime files. As of vidiff, I don't thing patching is the way. People who need vimdiff features can just as well install vim and get a whole lot more features with it. So I might just tank the vidiff symlink.

I think the more important issue here is that we incorrectly name "vim" "vi". vi is not vim; it's a different application; naming vim 'vi' just because you compile it with a lesser feature set makes no sense. Call the package vim-nox, vim-lite, or whatever else sounds good enough; and (this is how renaming would solve this issue:) don't rename the vim/vimdiff binaries/symlinks! They are named 'vim' and 'vimdiff' for a reason.

Well, I can technically compile --with-vim-name=whatever and it behaves excatly like vi unless you "set nocompatible", which is I guess the reason behind this configuration option. But all that doesn't help, because that feature is useless if the src really is looking for a vim* as name in order to work properly. The whole point here is to have an editor in base that people can use to edit their config files and they can access by some familiar name, such as vi (a vi binary is supposed to be present on every *nix system). A vim-nox just creates more damn confusion than it does help. On top of that I do not wanna install the runtime twice just because of a friggin naming issue.

Why not just remove the /usr/bin/vidiff symbolic link from the vi package? If the user wants to do a diff operation, then 'vi -d file1 file2' works as expected.

I would argue that vidiff isn't really a command required on a base system. If it is, then implement it as a shell script that does a 'vi -d' on the passed arguments.

I think that's the way to go, especially since you still can run a vi -d and that should give you the diff.

Actually the original 'vi' didn't even support a '-d' option. (See <http://ex-vi.sourceforge.net/>, and especially <http://ex-vi.sourceforge.net/vi.html>).

Vim is not a different application than vi, it is a modern successor to vi. Users expect the 'vi' command to invoke an editor with the basic functionality of vi. That is what the current Arch Linux vi package does. Making a 'vi' package based on the original 'vi' source code would just be a waste of developer resources.

This vim -> vi rename has one more undesired side effect: the editor doesn't highlight the syntax of its own configuration file (/etc/virc).

The Bill Joy "vi" editor did not support syntax highlighting. So not highlighting the /etc/virc is correct if strict 'vi' behavior is desired. Here is my proposed solution:
The "base" group of the "core" repository should have a "vi" package consisting of Vim running in strict vi-compatibility mode. And the "extra" repository should have one or more "vim" packages that provide enhanced Vim functionality. Installation of any "vim" package should cause the uninstallation of the "vi" package (is this possible?) and should symlink /usr/bin/vi to /usr/bin/vim. Users that want vi-compliant behavior would stay with the core vi package. And users that want more would install one of the "vim" packages. Would this resolve the issue to everyone's satisfaction?

Roger, except for the vi->vim symlink (we have two seperate, differently capable binaries), that is exactly what we do atm, I think.

But shouldn't installing the "vim" package cause the "vi" package to be uninstalled (or a least report a conflict)?
Doesn't anyone else have trouble remembering to type 'vim <filename>' instead of 'vi <filename>'? I frequently find that I'm editing a file using the wrong editor binary.
And it still seems that the 'vidiff' symlink should not be part of the "vi" package (to resolve the original reported bug).
Hope I'm not being a nuisance, this is just how I would address the issue. Really a minor nit.
Anyway, archlinux far exceeds any other distribution I've encountered. Well done!

Roger, that's exactly what it does. vi is always needed in order to have the runtime installed. We used to have a symlinking magic with renaming binaries and symlinking them in the install script. It didn't work all that well which is why we have the distinction between vi,vim and gvim now, each having it's own binary. I will get rid of the vidiff symlink as well since it just stirs trouble. Thanks for the kudos.

I excluded vidiff in the testing build
:wq