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

[Daenyth Blank]

On Thu, Mar 19, 2009 at 10:54, Andrei Thorp <garoth at gmail.com> 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 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-----
>

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)