Re: [aur-general] Arch's Vim Failings & Solution Suggestions
On Fri, 27 Mar 2009, Kessia 'even' Pinheiro wrote: > Hi! > > On Fri, Mar 20, 2009 at 12:19 PM, Tobias Kieslich > wrote: > > Hi, > > > > I was reaaly busy lately so I wasn't able to push tha changes I made > > locally. > > 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. > > Why not? becuase it is obviously missleading and a fair sourcve of confusion. > > > 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 > > Why base vi on nvi? nvi aren't updated (on website) since 4/14/01. The > last version of vi was based on vim and its a bit different for > compiling options only. I think this is fine for most of users. I > think in vi like a vim without X improvements, so, why not still with > vi based on vim? Maybe you can provide nvi in a different package, > which can provide vi, i dont know. We will base that on the devel version from 2007, whic is stable and works fine. Many other distros do the same. The advantages are listed above and there is a long thread on the bugtracker. The main advantage is that nvi is samller and as such much better suited for the base/core stuff. And if we move vi to extra there is hardly any point for having a vi over a vim package becuase the saving in space is marginal. Leaving KISS alone ... > > > 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. > > I understand the python idea here about explicit is better than > explicit, but vim dont need that, really. Well that iss the whole "assumption" theory. We 'assume' that the pathes are the same, but then the beginning of every catastrophy is a bloody assumption :P > > > 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 > > > > We are waiting until that... Yeah, there was a little issue called food poising, not pretty but well it happened. > > Well, for not be so long, I made some packages for vi/vim/gvim with > ruby1.9, for that I made a patch for vim (sent for vim_dev today) and > uploaded for ArchLinux-BR repository [repo.archlinux-br.org]. I I hope that will hit the vim upstream soon as it would help to keep the package clean. Thanks for the work. -T
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
Hi! On Fri, Mar 20, 2009 at 12:19 PM, Tobias Kieslich wrote: > Hi, > > I was reaaly busy lately so I wasn't able to push tha changes I made > locally. > 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. Why not? > 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 Why base vi on nvi? nvi aren't updated (on website) since 4/14/01. The last version of vi was based on vim and its a bit different for compiling options only. I think this is fine for most of users. I think in vi like a vim without X improvements, so, why not still with vi based on vim? Maybe you can provide nvi in a different package, which can provide vi, i dont know. > 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. I understand the python idea here about explicit is better than explicit, but vim dont need that, really. > 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 > We are waiting until that... Well, for not be so long, I made some packages for vi/vim/gvim with ruby1.9, for that I made a patch for vim (sent for vim_dev today) and uploaded for ArchLinux-BR repository [repo.archlinux-br.org]. I uploaded the packages with the PKGBUILD's on my home [http://even.archlinux-br.org/things/arch/packages]. For that I solve some bugs from flyspray[#13937 and #12440] and also the questions in the main of this thread. If you have any doubts, please reply me. -- Kessia Pinheiro Computer Science Student - Brazil, UFBa Linux System Administrator Arch Linux Trusted User Linux User #389695 http://even.archlinux-br.org --- X Fórum Internacional Software Livre - fisl10 24 a 27 de junho de 2009 PUCRS - Porto Alegre - Brasil
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
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 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 >
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
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
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
Fair enough, thank you. -AT On Thu, Mar 19, 2009 at 8:54 PM, Aaron Griffin wrote: > On Thu, Mar 19, 2009 at 7:44 PM, Andrei Thorp wrote: >> It's been mentioned to me that several bugs are open around these >> issues, and if this indeed the case, I believe it valuable to bring >> attention to them -- a mailing list cannot hurt. > > Well, at the very least, I'm sure the AUR mailing list is the wrong > place for this. > > But discussion on the bug tracker centralizes the facts, so I don't > have to go hunting around 4 different mailing lists, forum posts, and > things like that. >
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
On Thu, Mar 19, 2009 at 7:44 PM, Andrei Thorp wrote: > It's been mentioned to me that several bugs are open around these > issues, and if this indeed the case, I believe it valuable to bring > attention to them -- a mailing list cannot hurt. Well, at the very least, I'm sure the AUR mailing list is the wrong place for this. But discussion on the bug tracker centralizes the facts, so I don't have to go hunting around 4 different mailing lists, forum posts, and things like that.
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
It's been mentioned to me that several bugs are open around these issues, and if this indeed the case, I believe it valuable to bring attention to them -- a mailing list cannot hurt. -AT On Thu, Mar 19, 2009 at 1:07 PM, Aaron Griffin wrote: > On Thu, Mar 19, 2009 at 10:49 AM, Daenyth Blank > wrote: >> On Thu, Mar 19, 2009 at 11:35, Aaron Griffin wrote: >>> >>> What we could do is simply ship nvi instead, for that purpose, and >>> stick with only two packages, vim and gvim. That would help things >>> greatly. >>> >> >> +1 > > I just realized this was on the aur-general list. Silly place for this > discussion. > > Can we move this to the bug tracker? >
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
On Thu, Mar 19, 2009 at 10:49 AM, Daenyth Blank wrote: > On Thu, Mar 19, 2009 at 11:35, Aaron Griffin wrote: >> >> What we could do is simply ship nvi instead, for that purpose, and >> stick with only two packages, vim and gvim. That would help things >> greatly. >> > > +1 I just realized this was on the aur-general list. Silly place for this discussion. Can we move this to the bug tracker?
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
On Thu, Mar 19, 2009 at 11:35, Aaron Griffin wrote: > > What we could do is simply ship nvi instead, for that purpose, and > stick with only two packages, vim and gvim. That would help things > greatly. > +1
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
On Thu, Mar 19, 2009 at 9:54 AM, Andrei Thorp 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
> Date: Thu, Mar 19, 2009 at 2:29 AM
> Subject: Arch's Vim failings
> To: gar...@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].
>
> [0] - http://bugs.archlinux.org/task/10303
> [1] - if v:progname == 'vi'
> [2] - if has('cscope')
> [3] - globpath(&rtp, 'colors/*')
Thanks for sending this along. We're more than willing to fix and work
through problems that upstream has with the way we package software -
as we always say, we try to stay as close to upstream as possible.
So, couple of solutions I'd like to suggest:
The reason the vi package is... well, "jacked up", is because we
needed a small version to stick in our base package set, without a lot
of features. I guess this would be like vim-tiny on Debian.
What we could do is simply ship nvi instead, for that purpose, and
stick with only two packages, vim and gvim. That would help things
greatly.
Is not shipping a global /etc/gvimrc the norm? If so, we could do
that, and it would solve some annoyances I myself experienced (though
I rarely use gvim).
Regarding the runtimepath, that is a good point that scripts are
sourced twice. Definitely a bug and we should fix this.
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
Andrei Thorp wrote: There is a new vim setup on its way which should address some of these issues. Not sure what the status of it is though... Allan
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
Hi,
I had that problem too, i asked for something in #vim channel and they
only ridicularize vim package from Arch. I tried talk with Tobias
about the vim upgrade for support ruby1.9, but he are so far from fix
it, looking for problems which isnt important, in my vision. VI
package are with 65 patch, unless the oficial project are with more
than 100! I think it's a problem from arch package, but we need know
why it's so problematic for vim users dont like the package layout.
thanks
On Thu, Mar 19, 2009 at 11:54 AM, Andrei Thorp 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
> Date: Thu, Mar 19, 2009 at 2:29 AM
> Subject: Arch's Vim failings
> To: gar...@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
>
> [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-
>
--
Kessia Pinheiro
Computer Science Student - Brazil, UFBa
Linux System Administrator
Arch Linux Trusted User
Linux User #389695
http://even.archlinux-br.org
---
X Fórum Internacional Software Livre - fisl10
24 a 27 de junho de 2009
PUCRS - Porto Alegre - Brasil
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
Thanks for sending it along, Dae.
-AT
On Thu, Mar 19, 2009 at 11:01 AM, Kessia 'even' Pinheiro
wrote:
> Hi,
>
> I had that problem too, i asked for something in #vim channel and they
> only ridicularize vim package from Arch. I tried talk with Tobias
> about the vim upgrade for support ruby1.9, but he are so far from fix
> it, looking for problems which isnt important, in my vision. VI
> package are with 65 patch, unless the oficial project are with more
> than 100! I think it's a problem from arch package, but we need know
> why it's so problematic for vim users dont like the package layout.
>
> thanks
>
> On Thu, Mar 19, 2009 at 11:54 AM, Andrei Thorp 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
>> Date: Thu, Mar 19, 2009 at 2:29 AM
>> Subject: Arch's Vim failings
>> To: gar...@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
>>
>> [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-
>>
>
>
>
> --
> Kessia Pinheiro
> Computer Science Student - Brazil, UFBa
> Linux System Administrator
> Arch Linux Trusted User
> Linux User #389695
> http://even.archlinux-br.org
> ---
> X Fórum Internacional Software Livre - fisl10
> 24 a 27 de junho de 2009
> PUCRS - Porto Alegre - Brasil
>
Re: [aur-general] Arch's Vim Failings & Solution Suggestions
On Thu, Mar 19, 2009 at 10:54, Andrei Thorp 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
> Date: Thu, Mar 19, 2009 at 2:29 AM
> Subject: Arch's Vim failings
> To: gar...@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
>
> [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)
