On Thu, Mar 19, 2009 at 10:54, Andrei Thorp <garoth@xxxxxxxxx> wrote: > Hello, fellow Archers. > > Recently, I had a question about Vim, so I went to the #vim channel in > IRC. I was doing something > that should be working, but it wasn't. Surprisingly, the question came > up, "Are you on Arch?" > > Turns out that several of the peolpe I most respect in the #vim IRC > channel are very unhappy with the quality of Arch's Vim package. One > even (jokingly?) asked if they could officially not support Arch in > the channel, which I found somewhat alarming. I suggested that we > should instead help improve the Arch package. > > I hate to pick on people, but according to the generally kind folks on > IRC, the Vim package for Arch has quite a few issues, and the > maintainer hasn't addressed some outstanding bugs in quite a long > while. > > As some of you may know, James Vega (jamessan) is an outstanding Vim > user and the Debian package maintainer for Vim. I asked him to send me > what he saw as the problems with the Arch package, and he was kind > enough to send along some suggestions. They are attached in this > forward. > > Thank you, > > -Andrei Thorp > > ---------- Forwarded message ---------- > From: James Vega <jamessan@xxxxxxxxxx> > Date: Thu, Mar 19, 2009 at 2:29 AM > Subject: Arch's Vim failings > To: garoth@xxxxxxxxx > > > Andrei, > > Thanks for being receptive to trying to address the issues in Arch's Vim > packaging. Below are the major points that stand out. > > 1) gvim package: Shipping an /etc/gvimrc which, due to the order that > Vim loads rc files, overrides any settings in the user's ~/.vimrc. > Considering that some users make the conscious decision to keep all > their settings in their ~/.vimrc instead of using both ~/.vimrc and > ~/.gvimrc, this is at the very least annoying. More in depth > discussion is contained in the nearly year old, unfixed bug[0] about > this issue. > > 2) vi package: The package is built such that the resulting vi binary > reads its config from the completely non-standard ~/.virc. > Presumably this is to allow different configurations for the > different feature-sets avaiable in vi vs. vim packages. Fortunately, > Vim has methods to deal with this already such as being able to check > what name was used to invoke Vim[1] and explicitly checking for > feature support[2]. > > 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME > == $VIM by specifying "--with-global-runtime=/usr/share/vim" to > configure. This doesn't need to be specified to configure as it will > be set to the correct directory on its own. If they insist on > specifying it, the directory should be /usr/share/vim/vimXY (where XY > is Vim's version number -- 72 for current Vim). > > This manifests various problems, the most noticeable being that the > 'runtimepath' option in Vim has /usr/share/vim listed twice, thus > causing runtime files to be sourced twice and causing duplicate > information when using common scripting methods for discovering files > in the runtimepath[3]. > > -- > James > GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@xxxxxxxxxx> > > [0] - http://bugs.archlinux.org/task/10303 > [1] - if v:progname == 'vi' > [2] - if has('cscope') > [3] - globpath(&rtp, 'colors/*') > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis > xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX > =HJf3 > -----END PGP SIGNATURE----- > I don't have a whole lot to add to this, except that it seems like a good idea to confer with the vim developers to raise the quality of the package. I would file a bug report on the Arch tracker. (Also sending to arch-general, so this gets more exposure)
