[aur-general] Arch's Vim Failings & Solution Suggestions

[Andrei Thorp]

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 at debian.org>
Date: Thu, Mar 19, 2009 at 2:29 AM
Subject: Arch's Vim failings
To: garoth at gmail.com


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 at debian.org>

[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-----
-------------- next part --------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis
xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX
=HJf3
-----END PGP SIGNATURE-----