Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#10303 - [gvim] Package should not install a /etc/gvimrc file.

Attached to Project: Arch Linux
Opened by Dennis Craven (dcraven) - Monday, 28 April 2008, 02:57 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 13 June 2009, 09:47 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Kieslich (tobias)
Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When the vim/gvim packages are installed, they drop a gvimrc file into /etc. This causes problems as this file is sourced by vim *after* the user's ~/.vimrc file. Many users (myself included of course) do not maintain a separate ~/.gvimrc in favor of having a more robust ~/.vimrc file. Settings depending on gui/non-gui may be wrapped as follows:

; Only apply this in gvim
if has("gui-running")
set whatever
endif

; Only apply this in non-gui vim
if !has("gui-running)
set whatever
endif

The problem is that it is possible (and probable) that a user's settings can be overwritten by this file without the user's knowledge. Of course there are several ways the user can fix this (symlink ~/.vimrc -> ~/.gvimrc, delete /etc/gvimrc etc), but I suggest using the more robust method described in the examples above. This solution will work in all situations and will not overwrite user settings. In fact, gvim specific settings can be included in the non-gui vim package without any side-effects.

To summarize, I suggest the package only installs a /etc/vimrc (ie. no /etc/gvimrc) and that this single file contains specific settings for vim and gvim.

In my opinion this is a fairly significant bug because it causes side effects that give the appearance of a broken package.

Steps to reproduce:
Insert colorscheme settings in your ~/.vimrc file. Install the vim/gvim packages. Run gvim. Notice that your colorscheme colors are incorrect.
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Saturday, 13 June 2009, 09:47 GMT
Reason for closing:  Fixed
Additional comments about closing:  This should be fixed in the new vim setup. Request reopen if not.
Comment by Dennis Craven (dcraven) - Monday, 28 April 2008, 03:07 GMT
Attached to this comment is a rough example /etc/vimrc file. It contains the contents of both the stock /etc/vimrc and /etc/gvimrc files, however the latter is enclosed in 'if has("gui-running") ... endif' tags.
Comment by Dennis Craven (dcraven) - Monday, 28 April 2008, 03:38 GMT
Another (simpler) option is to inform the user after install about the /usr/share/vim/gvimrc_example.vim file and leave it at that. Don't install the /etc/gvimrc or it's contents at all.
Comment by Greg (dolby) - Monday, 28 April 2008, 09:25 GMT
So the problem is you dont want to create a .gvimrc file?
Comment by Dennis Craven (dcraven) - Monday, 28 April 2008, 10:35 GMT
No, the problem isn't so much that I don't want to make a ~/.gvimrc file (although I guess I don't). The problem is that some people do not have one since it is not necessary and they prefer to have and maintain a single, well-formed ~/.vimrc that handles the situation appropriately whether in GUI mode or not (in fact #vim on freenode promotes this practice).

The fact is having a ~/.gvimrc is not required unless there is a /etc/gvimrc installed system-wide as there is in Arch. Since the existence of a ~/.gvimrc is not required by Vim proper, some people don't maintain one. I've kept all of my Vim settings in a single .vimrc file for years. Every new machine I install on (for years it's been Debian or derivatives), I drop that .vimrc into my home directory and move on. This weekend I install Arch for the first time and do the same thing. When I start gvim, it's settings are messed up. I'm not the only one who has experienced this, there are several threads about it in the forum.

Sure, it's easy enough to fix as a user; Delete the /etc/gvimrc file every time you install gvim or there is a gvim update. But what if I'm not root? Then I'd have to create a ~/.gvimrc file with duplicate settings in it which is just asking for future breakage. In my opinion the best fix is to modify the package itself so that all situations are covered without breakage. This can be done by just not installing the sample gvim file to /etc/gvimrc.

Cheers. I appreciate your listening.
Comment by Aaron Griffin (phrakture) - Monday, 28 April 2008, 23:35 GMT
I agree with this for the most part. While the ordering is pretty much an upstream issue, it's an annoyance to almost everyone involved. It's probably a good idea to not ship the gvimrc file at all, and simply ship the stock vimrc file.

Opinions?
Comment by Dennis Craven (dcraven) - Tuesday, 29 April 2008, 00:02 GMT
Looking at the PKGBUILD, it's actually the /usr/share/vim/gvimrc_example that is being dropped into /etc. I'd bet these (including the vimrc_example) are only meant for reference, not intended as sane system wide defaults. That said, if the package maintainer feels they would like to provide system wide defaults, I don't see a huge problem as long as the values are chosen carefully and added in an /etc/vimrc (note *not* gvimrc). This would not conflict with user settings as the user's rc file is source after the system wide vimrc.

Probably the safest solution as a package maintainer, however, is to not install any rc files system wide, but mention the examples in the vim.install file instead. This would take the responsibility off of you to chose sane defaults for the Arch user base, and might be more in line with the Arch philosophy, depending on your interpretation of it :).

Your choice, of course.
Comment by Greg (dolby) - Tuesday, 29 April 2008, 12:26 GMT
IMO there is no perfect way to deal with this. The best way would probably be for gvim to use a vimrc configuration file instead of a gvimrc one and provide vim with a custom vimrc file that has if has gui running settings. Not providing system wide files is not a solution. (g)Vim should be useable upon installation.
Comment by Dennis Craven (dcraven) - Tuesday, 29 April 2008, 13:58 GMT
I'm trying to think of settings that should be put in the system-wide location and are relevant only to gvim and I can come up with nothing. Outside of nocompatible I can't think of many that should be set globally by default at all. I agree with Grigorios that an /etc/vimrc should be included with at least nocompatible set, but outside of that, settings should be chosen carefully. We shouldn't assume that the examples given with the upstream package are sane defaults. If upstream thought this, they probably would be default internally without the need for a vimrc file at all.

Any gvim specific settings that you deem worthy to include by default should be, as already covered, wrapped with 'if has("gui-running") ... endif" tags. This will guarantee no breakage of user specified settings.

PS. Sorry about the double post up there :/
Comment by Aaron Griffin (phrakture) - Tuesday, 29 April 2008, 16:36 GMT
Tobias, can we hand merge these config files, and commit them to svn, then only include it in the vim package? That seems the most sane to me.
Comment by Aaron Griffin (phrakture) - Friday, 09 May 2008, 05:51 GMT
Personally, I just symlink ~/.gvimrc to my ~/.vimrc, and that does the trick, but I still support this bug report, simply for the fact that it's confusing
Comment by Tobias Kieslich (tobias) - Friday, 09 May 2008, 06:25 GMT
I hear you guys. Here is the reason for my hesitance and why I actually don't wanna tinker with it too much: if vim is your religion, and many of us certainly think so, then vimrc is your friggin bible. So I don't like to rewrite this. First of all, yes, /etc/gvimrc is copied from a file that has_example in the file name but i don't care about filenames since content matters. And settings like "map <S-Insert> <MiddleMouse>" make a hell of a lot sense as system default, since they harmonize gvims behaviour with other applications. So I'm all in favour of NOT DROPPING IT!!!
However, that /etc/gvimrc overwrites setting from ~/.vimrc is absolutely not cool and frankly speaking I consider that an upstream issue. I will dig around a bit and maybe it is possible to change that order around to 1./etc/vimrc 2./etc/gvimrc 3. ~/vimrc and 4. ~/.gvimrc. If that doesn't fly We will have to find a way to merge the basic rc files into a single one. But I would prefer if we could fix the loading order.
Comment by Dennis Craven (dcraven) - Friday, 09 May 2008, 15:53 GMT
One potential problem with the symlink Aaron, is the redefinition of functions. Sure, this is worked around with a ! at declaration time, but should not be required.

IMHO, if the vimrc is your bible as mine is, then you have your own in $HOME. I'm not impressed when some system wide config tries to override my settings. In fact, I'd prefer no global settings at all. I'm not suggesting you remove the global settings altogether, but I do ask that you don't attempt to decide what makes sense for everyone on their behalf. I have many things in my ~/.vimrc that I'd say make a lot of sense, but I'd never expect them to be set as a system wide default.

You can of course go in the direction you please, and I can fix my own system no problem. Just keep in mind that you're trying to (I assume) create a quality package that works as expected for everyone. To me, this means keep the settings relatively close to the native defaults so that people coming from other distributions aren't surprised by weird behavior.
Comment by Matt Wozniski (godlygeek) - Tuesday, 14 October 2008, 07:16 GMT
There are plenty of problems with the symlink solution, not the least of which is the extra burden on the user to work around the package. Other problems include duplicated autocmds and user commands, appending to a string option instead of overwriting it will append twice, etc. Really, symlinking is no solution at all. The right thing to do is to not use the "example" gvimrc from upstream as a default system-wide gvimrc. It's not meant to be used that way; it instead contains some suggested settings that *users* might want in their own gvimrc. It's definitely worth noting that I don't know of any other distro that uses gvimrc_example as the default system-wide gvimrc.

It's also very unlikely that you'll be able to convince the upstream maintainer to change the loading order; Bram rarely agrees to anything that will break backwards compatibility unless there is no alternative. In this case, the Arch package can load the settings in gvimrc_example before the user vimrc just by putting this into /etc/vimrc:

if has('gui_running')
source /usr/share/vim/gvimrc_example.vim
endif

So, I think that's the best alternative in this case if you decide that the settings in gvimrc_example are really settings that ought to be enabled system-wide.
Comment by Gavin Bisesi (Daenyth) - Saturday, 21 March 2009, 14:15 GMT
This should be fixed in the new vim setup

Loading...