Arch Linux

I do not see anything changing the defaults in the PKGBUILD. Are you sure what you consider defaults actually are?

I copied those last 2 lines from comments in the vim help documentation. :h mouse and :h incsearch

and I've used vim in gentoo, windows, suse, centos, ubuntu (and more?) and never before encountered these settings. yet when I moved to arch I had to counter them. I'm not sure how they've been changed... I haven't investigated much yet. I assume that somehow in the vi/vim/gvim setups you've installed custom rc's. I also understand that problem is being worked on... and it had its own set of rc issues.

the /etc/vimrc file is a straight copy from vimrc.example shipping with the sources. that is considered the default. While I agree that some of the defaults are not the best, there are too many different opinions out there. This is why I really just encourage people to put whatever they want into ~.vimrc
All that is at least true for the new vim in testing.

that's an example not meant to be used as /etc/vimrc please read the documentation. as I've said documentation says these aren't the defaults. this file is not meant to be used to set default configuration (neither is the gvimrc) so stop using it.

from my irc conversation on #vim

[15:45] <xenoterracide> is vimrc_example.vim meant to e used as a default vimrc? I started a discussion with arch developers over defaults and apparently they use that file for /etc/vimrc which disagrees with vim documentation on just what defaults are
[15:46] <graywh> xenoterracide, no, the arch devs are "confused"
[15:46] <jamessan> xenoterracide, no it's meant as an example of common settings for you to read and make a decision about which settings you want to use

[15:56] <jamessan> xenoterracide, in fact, using the example vimrc is going to cause problems other than people being surprised by the default settings. since it calls "filetype plugin indent on", that prevents the user from being able to affect changes in certain aspects of Vim's behavior (as those changes need to happen before filetype plugins are enabled)
[15:56] <jamessan> (which is why I recently changed Debian's packaging not to enable them by default)

I am amazed by Tobias's patience. Bug reports like this one happens all the time regarding vim, the way its packaged, the defaults, the configuration file name or content. And he has only snaped once.
Anyway. Guess who's to blame for all these. Its the Vim developers. If the vimrc example gives bad examples tell them to change it themselves. Its their software. Whats the point in an example configuration file if it doesnt give you helpful tips?

it's for users, not distributors, that's an example for .vimrc not /etc/vimrc

also. I'm not trying to drag anyone down. now you know. I might have made the same mistake too. can we please get it fixed (instead of playing point the finger)? heck if you don't have anything you want to put in /etc/vimrc maybe you shouldn't even provide one by default.

So what do you consider as the "defaults from upstream" you wish not to be changed? Not having an /etc/vimrc file at all?

Since the vim stuff is in testing atm anyway, let's just get obn that one. Courtesy of vi's problem with the widechar support we'll have to wait for it to go live for a while. What's everybodies feeling on that? Personally I think the vimrc example is not too bad, I never reverted anything in it. Point is, some stuff a set nocompatible make a hell of a lot of sense, not setting it criplles vim severely. So it all comes down to where we draw the line. I can't please everyone, in fact I'm not even intending to do so. It's a compromise. But to stand my ground: Shipping no /etc/vimrc is probably a bad idea.

If I take a look at debian's default installation, there's only one sensible line in vimrc: the include of debian.vim. I'll attach the debian.vim so you can see what options they have. They only change some small annoying default settings, the rest is default.

The only noticeable difference is set nomodeline which " modelines have historically been a source of security/resource " modelines have historically been a source of security/resource"
See http://www.guninski.com/vim1.html . But I guess thats not important enough to give a hint in the example config file.

Errm i mean "modelines have historically been a source of security/resource vulnerabilities -- disable by default, even when 'nocompatible' is set" according to the debian.vim

the file looks good, I'll give that a shot later for testing. Still have to figure out the vi widechar stuff until it hits extra.:wq

I agree; the Debian vimrc is a good thing to mimic. Debian's /etc/vim/vimrc is meant to be edited by users, but by default, the only thing it does is source debian.vim (which is never meant to be edited by users) from the runtimepath, which sets nocompatible and then changes a few minor things. But /etc/vim/vimrc also provides a lot of commented out settings that the user can edit, and the comments include descriptions of what they will do if they're uncommented. I think this is a good middle ground between helping users to have a comfortable vim experience and forcing unwanted settings upon them. It makes vim behave nearly completely according to the upstream defaults, but provides a place where admins can put extra things for the comfort of their users, and points out what some of those extra things might be. Note that one thing that debian.vim *doesn't* do is enable filetype plugins, since that has some side effects that can never later be undone (see :help go-M). Regardless of where on the spectrum you want to fall, from many features enabled to strictly the upstream defaults, I think it's important that the user has the ability to turn off all of your customizations without editing the file, and that isn't possible when filetype plugins are included. I've attached a Debian /etc/vim/vimrc to show the sorts of commented settings it includes.

testing has a new vimrc scheme: /etc/vimrc soures /usr/share/vim/vim72/archlinux.vim where nothing for the mouse is set. If users wanna define their own behaviour, they are ought to put it into /etc/vimrc as I will never overwrite that file.

if users want to define there own behavior they should put it into ~/.vimrc unless they've a good reason to make it global for all users. but it is appropriate to never overwrite that file.