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

Andrei Thorp garoth at gmail.com
Fri Mar 20 16:10:47 EDT 2009


Thank you very much :)

Should be able to close at least one bug too.

-Andrei "Garoth" Thorp

On Fri, Mar 20, 2009 at 11:19 AM, Tobias Kieslich <tobias at justdreams.de> wrote:
> Hi,
>
>        I was reaaly busy lately so I wasn't able to push tha changes I made
> locally.
>> 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.
> I got rid of gvimrc in etc, I still wonder thought why they would
> have such a file upstream. Also virc is gone. Since we won't ship a vim
> based vi package anymore.
>>
>> 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].
> vi will be besad on nvi. that has lot's of advantages:
> - smaller for the iso
> - no waiting on testing that stalls vim and gvim
> - vi and vim are separated
>
>>
>> 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].
> I was not aware of the double loading, a testbuild showed me that it is
> easy to build both packages (vim/gvim) without the path specified. The
> idea behind specifying was that gvim and vim use the same runtime but
> only one package ships it. So being explicit instead of implicit seemed
> like a good idea to me. Anyway, that will be gone as well in the new
> layout.
>
> Hopefully tonight I can push them to testing. For the update people will
> be forced to remove the /usr/bin/vim and I think the /usr/bin/rview
> symlink manually. I tried to find a way around that, but no dice.
>
>        -T
>


More information about the aur-general mailing list