[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

vi, vim, and update-alternatives



I have done a new install of etch, and discovered a situation
that I find problematic. I don't know vi or vim well enough to
recognize which I am actually running by observing the behavior
of the running program, so some of my description of the situation
should be discounted if known to be untrue. But there is a problem:

When I run 
vi <file> 
, I get different behavior than when I run
vim <file>
.

When I was using Sarge, and early upgrades to Etch, I had avoided
using vim because I never felt I had the time to learn about its
'improved features'. Now, when I run vi, it behaves in a strange 
way that I dislike, and I can get back to what I thought was vi
behavior by running 'vim'. 

Then I looked at update-alternatives and it turns out that both are 
soft links that point to something called 'vim.tiny'. When I run
'vim.tiny' directly, it behaves like the new 'vim' and the old 'vi'.

There was no man page for vim.tiny, which, by itself, is reason for
complaint. But once I installed 'vim-doc', I discovered that vim,
and presumably vim.tiny, are programmed to behave differently
depending on the name under which the program in invoked. The
names that are documented are:

vim, ex, view, gvim, gview, evim, 
eview, rvim, rview, rgvim, rgview.

'vi' is not in this list, so I can't say what vim.tiny should do when
it is invoked via the update-alternatives symlink, vi, but I think it
is not doing something that its maintainers intend. Is this a bug? Or
is it working in some mode that is useful, but only to those users who
are familiar with that secret?

(Running under the special name 'vim.tiny' is also undocumented
behavior, but here, the behavior is what a naive user would expect.)

I suppose that separating out vim-doc into a package by itself is a
convenient way to keep Debian small for server boxes, but can't
vim-doc be included in the 'Desktop environment' task in tasksel?
Surely it is not large in comparison to, say, xserver.

On a deeper level, I am uneasy about using names of common programs, 
such as vi, vim, emacs, etc. as the names of symlinks in /usr/bin.
It works, but is very misleading to new users who fancy themselves
quite familiar with UNIX-like systems.

Your responses to this kvetching will help me decide whether to file a
bug report, and against what package.

Thanks.
-- 
Paul E Condon           
pecondon@mesanetworks.net



Reply to: