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
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
|
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.
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.
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.
Opinions?
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.
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 :/
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.
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.
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.