[arch-dev-public] Vi package

Tobias Kieslich tobias at justdreams.de
Thu Feb 10 14:39:08 EST 2011


this comes up every once in a while, and while the current situation is
not exactly satisfying, it's IMHO the best compromise we have. Here is

In my and many others opinion, vi sole purpose ist to maintain standard
compliance plus to serve as simple editor on install time. For
everything else, let me repeat that: EVERYTHING ELSE, please install
vim. Thank you!
So, why not have vim, a mini vim, vim-tiny, a stripped version of vim
instead? Because it's a lot of work and more importantly a damn error
prone thing to do for very little benefit. Vim, no matter how stripped
down, comes with a significant runtime. This runtime needs to be
stripped down manually but still will be bigger than ex-vi and friends.
Moreover, any vim/gvim package must be designed complementary to 
	a) provide everything the stripped vi doesn't have
	b) don't conflict with with the stripped vi
That is a lot of work and very error prone. We had that partially in the
past and let's just say it didn't go so well. Did anyone notice the 
release speed of vim? It needs to be rechecked and veryfied for every
release. On top of that, because vi will be in core, every vim/gvim
release will have to be delayed by the testing period for vi. That too
we did have in the past and it doesn't ring so well with both users and

So in conclusion, I see very little benefit in having a more functional
vi package, when most can be achieved by installing vim for what you
wanna do in the editor. The difference in typing "vi" or "vim" is a
rather semantic one and if you really can't stand it, Jan's symlink idea
works just fine. The cost for splitting it in a vi and a vim packag is
simply way to high.

	- T

On Wed, 09 Feb 2011, Stéphane Gaudreault wrote:

> Hi,
> I was looking at FS#20778 and was wondering what we should do with it. 
> While it is true that the "traditional vi" is buggy and not user friendly. It 
> does not seems that BusyBox is a good alternative.
> There are options here:
> 1) Statu quo
> Pro : 
>    * Support for multi-byte character encodings like UTF-8
>    * Small size
> Cons :
>    * Did I said that it is buggy ?
>    * Use of this old software in the installer may give a strange impression 
> to new users as they are faced with an editor from the '70 on a distro where 
> everything is up to date.
>    * Appears to be no longer be updated upstream.
> 2) nvi
> Pro :
>    * Small size 
>    * More advanced features : multiple undo, command history, filename 
> completions, multiple edit buffers, etc.
>    * Version of vi that is shipped with {Free,Open,Net,DragonFly}BSD
> Cons :
>    * No support for muti-byte character encoding
>    * Appears to be no longer be updated
> 3) elvis
> Pro :
>    * Small size
>    * Advanced features
>    * Shipped with Slackware and Debian
> Cons :
>    * the editor has been abandoned upstream since about March 2004.
>    * the Debian package has only an incomplete implementation of support for 
> multi-byte characters
> 4) A compact version of vim
> http://packages.ubuntu.com/en/maverick/vim-tiny
> https://github.com/BlackIkeEagle/herecura/tree/master/herecura-stable/vim
> Pro :
>    * Most popular vi implementation
>    * Advanced features
>    * UTF-8 support
>    * Avoid dependency on vim-runtime.
> Cons :
>    * Size : not as bloated as the full vim, but larger than ex/vi. On Ubuntu 
> x86_64, installation size is 836 kB which is reasonable.
>    * May need a duplicate PKGBUILD as vim is in [extra] while vi is in [core]
> Opinions?
> Stéphane

More information about the arch-dev-public mailing list