[vim/vim] Certain configs in /etc/vimrc are ignored if ~/.vimrc does not exist (#2042)
djddjd
If ~/.vimrc doesn't exist, some configs in /etc/vimrc has no effect. E.g.
set scrolloff=<n>
Some configs changes the behaviour. E.g.
highlight Todo
doen't work. I have to use
highlight cTodo
These configs works after I create an empty ~/.vimrc file.
Version Information:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Aug 24 2017 18:10:32)
Included patches: 1-987
Compiled by root@dj
Huge version without GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_sgr +tag_old_static
+arabic +find_in_path -mouse_sysmouse -tag_any_white
+autocmd +float +mouse_urxvt +tcl
-balloon_eval +folding +mouse_xterm +termguicolors
-browse -footer +multi_byte -terminal
++builtin_terms +fork() +multi_lang +terminfo
+byte_offset +gettext -mzscheme +termresponse
+channel -hangul_input +netbeans_intg +textobjects
+cindent +iconv +num64 +timers
-clientserver +insert_expand +packages +title
-clipboard +job +path_extra -toolbar
+cmdline_compl +jumplist +perl +user_commands
+cmdline_hist +keymap +persistent_undo +vertsplit
+cmdline_info +lambda +postscript +virtualedit
+comments +langmap +printer +visual
+conceal +libcall +profile +visualextra
+cryptv +linebreak +python +viminfo
+cscope +lispindent -python3 +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con +lua +rightleft +windows
+diff +menu +ruby +writebackup
+digraphs +mksession +scrollbind -X11
-dnd +modify_fname +signs -xfontset
-ebcdic +mouse +smartindent -xim
+emacs_tags -mouseshape +startuptime -xpm
+eval +mouse_dec +statusline -xsmp
+ex_extra +mouse_gpm -sun_workshop -xterm_clipboard
+extra_search -mouse_jsbterm +syntax -xterm_save
+farsi +mouse_netterm +tag_binary
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE -L/usr/local/lib -Wl,--as-needed -o vim -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -L/usr/lib -llua -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE -fstack-protector -L/usr/local/lib -L/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -L/usr/lib64 -ltcl8.5 -ldl -lpthread -lieee -lm -Wl,-R -Wl,/usr/lib64 -L/usr/lib64 -lruby -lpthread -lrt -ldl -lcrypt -lm -L/usr/lib64
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Christian Brabandt
Are you sure? I cannot reproduce this. Check with :scriptnames Also perhaps the defaults.vim comes into your way?
djddjd
@chrisbra Yes, you are right. defaults.vim is the reason. Patch 7.4.2111 has introduced this feature.
patch 7.4.2111
Problem: Defaults are very conservative.
Solution: Move settings from vimrc_example.vim to defaults.vim. Load defaults.vim if no .vimrc was found.
defaults.vim can be ignored if I add let skip_defaults_vim = 1 in /etc/vimrc. With this line the configs are back again.
djddjd
Closed #2042.
James McCoy
For what it's worth, Vim's behavior would be much more predictable (both to the end user and to sysadmins wondering why their system-wide settings are suddenly being overridden) if defaults.vim was loaded first instead of last.
If it's imperative that defaults.vim is only loaded when the user doesn't have their own vimrc file, then why check which of the init files exist first and then load the relevant init files, starting with defaults.vim. This ensures that sysadmin settings in the system vimrc are respected, but still provides more usable defaults to the end user.
Bram Moolenaar
James McCoy wrote:
> For what it's worth, Vim's behavior would be much more predictable
> (both to the end user and to sysadmins wondering why their system-wide
> settings are suddenly being overridden) if defaults.vim was loaded
>
> If it's imperative that defaults.vim is only loaded when the user
> doesn't have their own vimrc file, then why check which of the init
> files exist first and then load the relevant init files, starting with
> defaults.vim. This ensures that sysadmin settings in the system vimrc
> are respected, but still provides more usable defaults to the end
> user.
It would actually be more predictable if there is no system wide vimrc
or it only sets system-specific things (e.g. path of tools).
There is hardly a reason to overrule Vim defaults, especially now that
the defaults are "more modern".
I expect users to work on multiple systems. Best is when Vim works the
same everywhere out of the box, or with the user provided vimrc. A
system vimrc is often causing unexpected differences.
--
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
-- Dave Parnas
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
James McCoy
It would actually be more predictable if there is no system wide vimrc
or it only sets system-specific things (e.g. path of tools).
There is hardly a reason to overrule Vim defaults, especially now that
the defaults are "more modern".
Well, Vim changed its defaults. Not only that, but it did so in a way that ignores the settings sysadmins placed in the system-wide vimrc, while at the same time enabling functionality (in particular "set mouse=a") that causes a drastic change in behavior.
I've received numerous complaints (in the context of maintaining Debian's Vim packages) from people that were quite upset about Vim suddenly swallowing their mouse, thus breaking their use of X's PRIMARY selection, and not knowing how to fix it or that you can hold shift to override the behavior in most terminals. Ubuntu and Fedora have specifically disabled the mouse part of defaults.vim. They wouldn't have to do that if system-wide settings were honored, as sysadmins have expected from Vim for the past 25 years.
Similarly, I've received many complaints about the fact that root's vim suddenly acted differently, since it commonly doesn't have a personal vimrc. There were also many people that just put their config in the system vimrc so there's consistent behavior across accounts, and then Vim stopped doing what they expected.
All of this is with me adding NEWS items explaining that Vim changed defaults and how to override them.
Bram Moolenaar
James McCoy wrote:
> > It would actually be more predictable if there is no system wide vimrc
> > or it only sets system-specific things (e.g. path of tools).
> > There is hardly a reason to overrule Vim defaults, especially now that
> > the defaults are "more modern".
>
> Well, Vim changed its defaults. Not only that, but it did so in a way
> that ignores the settings sysadmins placed in the system-wide vimrc,
> while at the same time enabling functionality (in particular "set
> mouse=a") that causes a drastic change in behavior.
>
> I've received numerous complaints (in the context of maintaining
> Debian's Vim packages) from people that were quite upset about Vim
> suddenly swallowing their mouse, thus breaking their use of X's
> PRIMARY selection, and not knowing how to fix it or that you can hold
> shift to override the behavior in most terminals. Ubuntu and Fedora
> have specifically disabled the mouse part of defaults.vim. They
> wouldn't have to do that if system-wide settings were honored, as
> sysadmins have expected from Vim for the past 25 years.
mouse!"? Changing defaults always cause some users to complain. From
experience I can say that if it's less than 5% we did a very good job.
But those 5% can still be quite a few users and they can be very vocal
about it.
Unfortunately, doing research on things like this is very time
consuming, if possible at all (would you like to fill in a feedback form
about Vim, or report the request it as spam?).
This I make a best guess.
> Similarly, I've received many complaints about the fact that root's
> vim suddenly acted differently, since it commonly doesn't have a
> personal vimrc. There were also many people that just put their
> config in the system vimrc so there's consistent behavior across
> accounts, and then Vim stopped doing what they expected.
>
>
> All of this is with me adding NEWS items explaining that Vim changed
> defaults and how to override them.
hundred-and-one symptoms of being an internet addict:
103. When you find yourself in the "Computer" section of Barnes & Noble
enjoying yourself.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
James McCoy
And how many users said "finally!" or "I didn't know I could use the
mouse!"? Changing defaults always cause some users to complain.
Probably fewer than could have, since the actual defaults weren't changed. Instead, a script that is sometimes, but not always, sourced modifies the defaults. More users would have those "a ha!" moments and people would be able to use known mechanisms to modify the settings if the defaults had been changed.
Instead, there's a bad mix of behaviors which is more confusing than useful. It's useful to think about who should benefit from the change and how they can adapt to it.
A novice user with no vimrc starts using Vim with the defaults.vim loaded. They find something the want to change and create a ~/.vimrc. Suddenly, they've lost all the behaviors that defaults.vim was providing, likely without realizing it was defaults.vim providing that functionality.
A novice user with a vimrc copied from /etc/skel doesn't ever benefit from these new defaults, even though they didn't create the vimrc (which is being treated as a flag for "Leave my config alone, I know what I'm doing").
An experienced user with a customized vimrc, but maybe one that doesn't know about a feature enabled in defaults.vim, won't be exposed to these useful changes because defaults.vim isn't loaded.
A sysadmin that only sometimes uses Vim to edit system config files now suddenly has Vim change behavior, so they try to override the behavior in the system vimrc but that doesn't help.
A sysadmin that was providing some common defaults to their users is now being overridden by defaults.vim.
Overall, defaults.vim provides minimal benefit and doesn't let people adjust the behavior by simply putting some "set" statements in their config. Loading defaults.vim first would help with the precedence issue, but not with the issue of people not being exposed to these "useful" settings.
Actually changing the defaults in the source solves both issues, since the new behavior is consistently exposed to all users and the normal mechanisms for changing options still apply.
Christian Brabandt
@jamessan you raised many valid points. But is there an actual issue you are trying to solve here? I have the feeling we are just discussing what went wrong or what could have solved otherwise. Besides complaining (sorry for accusing) is there anything we need to do here? Would a :ru defaults.vim in your system vimrc not fix most of those issues (assuming the system vimrc is maintained by the distributors) and further customized by the sysadmins?
James McCoy
But is there an actual issue you are trying to solve here?
Yes, I'm trying to show that the existing solution is confusing and not meeting the intended expectations. Let's fix that instead of carrying on with it.
Would a :ru defaults.vim in your system vimrc not fix most of those issues
Why should every sysadmin have to learn to do that? For years they've been able to just drop "set" commands into their system vimrc to modify the behavior of Vim. Now they have to learn a different way to do things to work around an ineffective way of providing improved defaults to users.
If it's truly beneficial to make change the defaults, then why have a convoluted way to do it instead of just changing the defaults?
Christian Brabandt
well, we have this now for a while and if we change it now, this will again lead to a great confusion for users. So I am wondering why you make those comments now and not 1 year ago when defaults.vim was introduced.
Let's fix that instead of carrying on with it.
So you propose to drop defaults.vim now and simply change the C defaults? While I'd like to have that changed a year ago, I wonder if we do it now, if this won't create even more confusion. Or what exactly would you propose?
Why should every sysadmin have to learn to do that?
That was not was I meant. I thought more of a template file, where sysadmins can add additional settings and which by default sources the defaults.vim file (meaning the distributor provides this part).
Now they have to learn a different way to do things to work around an ineffective way of providing improved defaults to users.
That is simply not true. If sysadmins would start using a .vimrc file, nothing changed at all.
James McCoy
So I am wondering why you make those comments now and not 1 year ago when defaults.vim was introduced.
I did -- 8c08b5b#commitcomment-19939890. Although, I guess at that point it wasn't totally clear to me how unintuitive the behavior was going to be. We learn more as more people encounter the new behavior. We should be able to adjust based on that.
I've also told all the Debian users that complained about it that they should bring it up on the Vim lists, since I donn't want to deviate from upstream's behavior. Unfortunately, it seems like they didn't take me up on that.
So you propose to drop defaults.vim now and simply change the C defaults?
Yes.
While I'd like to have that changed a year ago, I wonder if we do it now, if this won't create even more confusion.
Being able to override defaults by changing the option you don't like is confusing?
where sysadmins can add additional settings and which by default sources the defaults.vim file
Instead of Vim just having defaults that everyone can rely on, the distributors have to either disable loading of defaults.vim, preventing users from getting its benefits, or force loading of the file so people can adjust the behavior by normal means?
Now they have to learn a different way to do things to work around an ineffective way of providing improved defaults to users.
That is simply not true. If sysadmins would start using a .vimrc file, nothing changed at all.
Except that they haven't needed a .vimrc for years. They could use a system vimrc and their settings would be honored. Now the settings aren't honored unless they learn to disable a random file.
I'm not disagreeing with (most) of the actual default changes, just the implementation.
Christian Brabandt
So you propose to drop defaults.vim now and simply change the C defaults?
Being able to override defaults by changing the option you don't like is confusing?
Are you trying to misunderstand me? Users now might be familiar with defaults.vim and then wonder why it is not respected anymore.
Except that they haven't needed a .vimrc for years. They could use a system vimrc and their settings would be honored. Now the settings aren't honored unless they learn to disable a random file.
okay, so would it be acceptable to skip loading defaults.vim when a system vimrc has been loaded? Something like this patch:
diff --git a/src/main.c b/src/main.c index 3b18bf1e4..6d292ace7 100644 --- a/src/main.c +++ b/src/main.c @@ -3015,6 +3015,9 @@ source_startup_scripts(mparm_T *parmp) } else if (!silent_mode) { +#ifdef SYS_VIMRC_FILE + int did_source_sysvimrc = FAIL; +#endif #ifdef AMIGA struct Process *proc = (struct Process *)FindTask(0L); APTR save_winptr = proc->pr_WindowPtr; @@ -3027,7 +3030,7 @@ source_startup_scripts(mparm_T *parmp) * Get system wide defaults, if the file name is defined. */ #ifdef SYS_VIMRC_FILE - (void)do_source((char_u *)SYS_VIMRC_FILE, FALSE, DOSO_NONE); + did_source_sysvimrc = do_source((char_u *)SYS_VIMRC_FILE, FALSE, DOSO_NONE); #endif #ifdef MACOS_X (void)do_source((char_u *)"$VIMRUNTIME/macmap.vim", FALSE, DOSO_NONE); @@ -3062,6 +3065,9 @@ source_startup_scripts(mparm_T *parmp) && do_source((char_u *)USR_EXRC_FILE, FALSE, DOSO_NONE) == FAIL #ifdef USR_EXRC_FILE2 && do_source((char_u *)USR_EXRC_FILE2, FALSE, DOSO_NONE) == FAIL +#endif +#ifdef SYS_VIMRC_FILE + && did_source_sysvimrc == FAIL #endif && !has_dash_c_arg) {
I think that should be acceptatble. Users compiling their own Vim probably don't have a system vimrc file so nothing should be changed. And distributors can still install their own system vimrc file and (loading the defaults vim would then be skipped (or even better, it should source the defaults.vim file).
Christian Brabandt
to the users of the mailinglist, updated previous comment and removed the first line
James McCoy
would it be acceptable to skip loading defaults.vim when a system vimrc has been loaded?
That would at least make the behavior consistent. I still think that conditionally loading defaults.vim after all the other rc files is wrong, for the reasons I described earlier (#2042 (comment)), but I'd take your proposed change over nothing happening.
Christian Brabandt
Reopened #2042.
Christian Brabandt
but I'd take your proposed change over nothing happening.
I am trying to be helpful here.
I am always thinking of defaults.vim only being sourced once no vimrc has been found, however the documentation explicitly talks about user vimrc files as I see now. I also think it would be more consistent to only source it once no vimrc file has been found (regardless of being system vimrc or user vimrc).
Let's see what Bram thinks.
Christian Brabandt
I happened to come across some more discussions about the unexpected behaviour in the german debian-user list. Apparently, this affects many users, that use the system vimrc for configuration, do not have a custom user vimrc and there exists no way to overrule the defaults.vim file. Especially the 'mouse' setting seems to cause a lot of negative feedback. Unfortunately, nobody seems willing to give feedback here.
So I think we definitely need some adjustment here.
Feedback on the suggested patch would be welcome.
Wouter Verhelst
As a small data point:
I just stumbled upon this bug through unrelated means, and I had a big "aha-erlebnis".
I'm not a very advanced vim user. I've been using it for about fifteen years now and can get around, but I never immersed myself into the documentation, simply because it's just an editor and I can't really be bothered.
Over the past year, I've been incredibly frustrated with vim. Its behaviour became erratic; sometimes it would do one thing, sometimes it would do another. Sometimes the mouse would work, sometimes it would not. When I changed things in ways that used to work, it did not this time. I had no clue what was happening, and no idea where to start to fix it. Now that I know about defaults.vim, a whole lot of things are falling into place, and I can make sense of things again, and possibly have a chance at fixing them.
The behaviour where vim changes completely unrelated settings upon the existence of some file is extremely counter-intuitive. On my system, ~/.vimrc contains a single line ("set noincsearch", although /etc/vim/vimrc has a few more). I expected that that single line would be the only setting changed by the existence of that file. I have now learned that this (completely reasonable, IMAO) assumption is not true, and that there are a whole slew of other changes that will be triggered if I ever remove that file. From where I'm standing, this is extremely counter-intuitive to users. Please fix this unreasonable behaviour.
I concur with James: the proper thing to do would be to have defaults.vim be loaded always but to allow its settings to be overridden. I do not know why the current behaviour was implemented as is; I can only suspect that this was done so that highly experienced vim users with a highly customized ~/.vimrc would not have to edit it at every new vim version. I submit that to cater to such users, vim is now making life much more complicated for the intermediate users who have no clue what's going on and who are as confused about it as me. If this was indeed the rationale, I submit that the following would be a better solution:
- if a vimrc file contains a "set nodefaults" or something, then loading defaults.vim is skipped
- otherwise, in all other cases and regardless of whether ~/.vimrc even exists, defaults.vim is loaded at the end, but it does not touch any settings that were already changed in a previous rc file.
I guess that implementing that sort of behaviour would be complicated, but I think it's the best possible behaviour if my assumption above is correct.
(also, proud that I managed to get through that without commenting on the censored mouse swallowing behaviour of recent vim)
Christian Brabandt
Would it be more consistent for you, if defaults would have been skipped by loading of the system vimrc file?
without commenting on the censored mouse swallowing behaviour of recent vim
I have heard more reports about this (but do not remember any actual bug reports/issues). Is this some kind of reproducable behaviour?
James McCoy
I have heard more reports about this (but do not remember any actual bug reports/issues).
That's probably something like https://groups.google.com/d/msg/vim_dev/m0523tjJClw/3E_zMyGlCAAJ.
Wouter Verhelst
Would it be more consistent for you, if defaults would have been skipped by loading of the system vimrc file?
No. Defaults are part of the standard behavior of an application. When I change one option, I expect that only that one option changes behavior, and nothing else. It should not matter where I make that change.
I have heard more reports about this (but do not remember any actual bug reports/issues).
That was a reference to the set mouse thing which defaults.vim sets. In my opinion, text-mode applications have no business talking to the mouse, and if they do so anyway they're annoying. Luckily it's only a setting that can be changed though. Unluckily the defaults also set some things that I do think make sense, and so if I just want to switch off the IMHO broken mouse behavior I first have to copy most of defaults.vim to my own config file. That makes no sense.
Wouter Verhelst
So, giving this some more thought,
if a vimrc file contains a "set nodefaults" or something, then loading defaults.vim is skipped
otherwise, in all other cases and regardless of whether ~/.vimrc even exists, defaults.vim is loaded at the end, but it does not touch any settings that were already changed in a previous rc file.
It's actually easier to do as follows:
- defaults.vim is loaded always, unconditionally
- Create a new file, say, "baseline.vim" or some such, which mirrors everything that defaults.vim does. That is, if defaults.vim sets something, baseline.vim would unset it.
If users who set up their vimrc just right and don't want anything to change upon version upgrade (which I assert are just a vocal minority) just load baseline.vim, somewhere at the top of their .vimrc, then they can be happy.
Changing defaults to showcase new features is a good thing. It should not be hidden just because a user changed one or two minor settings and therefore created a ~/.vimrc. It should not be the cause of the kind of confusing behaviour that we see now. Changing defaults upon version upgrade should happen for everyone who did not explicitly ask otherwise.
It might be a good idea to organize defaults.vim in such a way that it can be easily reviewed for the most recent changes; e.g., add new changes at the bottom, and add comments stating the date or the vim version when a change is made. That way, if defaults.vim changes three things on a new version and I love two of them but hate the third, I can more easily figure out what changed and undo it in my own .vimrc. I don't know if this is already the case though.
Anyway, that'll be my last message on the subject ;-)
Bram Moolenaar
Wouter Verhelst wrote:
> So, giving this some more thought,
>
> > if a vimrc file contains a "set nodefaults" or something, then loading defaults.vim is skipped
> > otherwise, in all other cases and regardless of whether ~/.vimrc even exists, defaults.vim is loaded at the end, but it does not touch any settings that were already changed in a previous rc file.
>
> It's actually easier to do as follows:
>
It was like that at first, but lots of existing users complained about
it.
The current solution is a compromise, it's simply impossible to please
everbody.
> * Create a new file, say, "baseline.vim" or some such, which mirrors
> everything that defaults.vim does. That is, if defaults.vim sets
> something, baseline.vim would unset it.
>
> If users who set up their vimrc just right and don't want anything to change upon version upgrade (which I assert are just a vocal minority) just load baseline.vim, somewhere at the top of their .vimrc, then they can be happy.
since that is a change.
> Changing defaults to showcase new features is a *good* thing. It should not be hidden just because a user changed one or two minor settings and therefore created a ~/.vimrc. It should not be the cause of the kind of confusing behaviour that we see now. Changing defaults upon version upgrade should happen for everyone who did not explicitly ask otherwise.
Every time a default changes users do complain. In fact, your complaint
is exactly that.
> It might be a good idea to organize defaults.vim in such a way that it can be easily reviewed for the most recent changes; e.g., add new changes at the bottom, and add comments stating the date or the vim version when a change is made. That way, if defaults.vim changes three things on a new version and I love two of them but hate the third, I can more easily figure out what changed and undo it in my own .vimrc. I don't know if this is already the case though.
>
> Anyway, that'll be my last message on the subject ;-)
SOLDIER: What? A swallow carrying a coconut?
ARTHUR: It could grip it by the husk ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
James McCoy
- defaults.vim is loaded always, unconditionally
It was like that at first, but lots of existing users complained about
it.
Presumably because it's awkward to override defaults.vim, since it is loaded after the user's vimrc.
There are two suggestions that seem viable to me.
-
Make the defaults actually defaults and set them before any other init files are loaded. This both exposes users to new, potentially useful behaviors but also makes it easy for them to override the behavior they don't like.
-
Keep the current "don't load defaults.vim" if a user has a vimrc file, but also account for system vimrc files. This is the patch Christian has proposed. You lose the exposure to new behavior aspect, but it makes Vim consistently ignore defaults.vim when any vimrc file is present.
Ben Fritz
> Unluckily the defaults also set some things that I do think make sense, and so if I just want to switch off the IMHO broken mouse behavior I first have to copy most of defaults.vim to my own config file. That makes no sense.
>
Instead of copying you can just source defaults.vim in your .vimrc, prior to turning off any options you don't like.
cheater
Here's my point of view. I have upgraded from 7.2 to 8.0 today. I have started noticing weird behavior with scrolloff not being settable.
I change my settings in /etc/vim/vimrc.local which is sourced by default from /etc/vimrc. I have no ~/.vimrc. It took a longer period of time to figure out that this is set in defaults.vim.
As I understand it, the issue is:
- we want defaults.vim for most users
- we don't want to set the defaults if the users don't want them.
My issue was that I didn't understand that defaults.vim was being sourced.
For 1 to work defaults.vim obviously needs to be sourced at /some/ point. However, we don't want defaults.vim to set a bunch of features that everyone will then have to turn off. So defaults.vim can't be always sourced before all other scripts.
As I understand it, currently defaults.vim is not sourced from any rc files, it's sourced by vim directly when it doesn't find ~/.vimrc. This mechanism is hidden and therefore difficult to discover for users.
My first suggestion is that you also check for /etc/vim/vimrc.local. But this is distribution-specific, so maybe the following is better instead.
A better suggestion is that instead of sourcing defaults.vim from vim directly, this sourcing is done in /etc/vimrc with a conditional that checks for ~/.vimrc and loads defaults.vim if it isn't found. This has several potential benefits:
- this can be overridden
- the rules are stated directly in a file that the user will read right away when trying to debug surprising behavior, in a way such that the user can understand them
- anyone who doesn't want it can remove it from /etc/vimrc without putting garbage in $HOME
- package maintainers can customize this logic. For example, on Debian and Ubuntu /etc/vim/vimrc.local is a file similar to ~/.vimrc except it's global for all users. Vim should not load defaults.vim when /etc/vim/vimrc.local is present. Package maintainers should be able to do this without modifying Vim source code.
- People would now have a good way of figuring out that there actually is a defaults.vim. I didn't know. I wouldn't have ever known had it not been for its obvnoxious behavior. It's nice to have a defaults.vim but it should also be possible to discover it easily. Refering to it in /etc/vimrc will be a good, very public way of mentioning it. As things stand right now, most users do have a ~/.vimrc of some sorts, so they do not benefit from a defaults.vim in any way, and they have no way of figuring out it exists, unless they inspect packages or read change logs (most don't).
- you can still source defaults.vim from ~/.vimrc or /etc/vim/vimrc.local if you want, especially now that you know about it.
- The package maintainer can make up their own mind over whether defaults.vim is loaded before or after ~/.vimrc or if at all when that exists, and whether it should be loaded before or after /etc/vim/vimrc.local or at all if that exists. I think that's a thing package maintainers should be able to do on their distros in order to meet the requests and complaints of their users.
cheater
One thing should be born in mind: some people might have gotten used to how defaults.vim is loaded right now. As I understand it, this only matters in the very unusual scenario where a user only has an /etc/vim/vimrc.local but no ~/.vimrc, and where they rely on defaults.vim ignoring something they set in /etc/vim/vimrc.local. They are users who would be on a sad path, but their sad path is really easy for them to fix: they just need to source $VIMRUNTIME/defaults.vim at the end of their /etc/vim/vimrc.local or something like that.
Other than that one pathological situation, if we go back to the moment just before when defaults.vim was introduced, and consider the solution I propose, I think it should actually make everyone happy. Unlike @brammool said, it's possible :-) And since then, the only thing that changed is the pathological situation I describe at the top of this comment.
Bram Moolenaar
All these problems won't exist if there is no /etc/vimrc. Just use the Vim defaults, which are documented and the same on all systems. There is no reason Vim should work different on debian/ubuntu/suse or whatever distribution, just because some maintainer has a different idea about what defaults to use and enforce this upon all their users.
Bram Moolenaar
Closed #2042.
cheater
that probably makes sense, it's better to keep things simple.
Justin M. Keyes
All these problems won't exist if there is no /etc/vimrc. Just use the Vim defaults, which are documented and the same on all systems. There is no reason Vim should work different on debian/ubuntu/suse or whatever distribution, just because some maintainer has a different idea about what defaults to use and enforce this upon all their users.
Incidentally, that's what I have advocated for years.
Problem is:
- That should have been advocated 15 years ago, by Vim core maintainers. I've never seen this mentioned on vim_dev.
- Vim's defaults aren't good.
James McCoy
All these problems won't exist if there is no /etc/vimrc.
Then why does Vim support a system-wide vimrc file at all? Since it does support the concept of a system-wide vimrc, it should treat that vimrc the same as any other vimrc file from the perspective of determining whether to load defaults.vim.
That would minimize the already surprising behavior of defaults.vim.
There are reasons to put system-specific configuration into the system vimrc. Are there some things that should be removed from the system vimrc that distributions use? Probably, but there are also things that can't be removed.
As I stated before, this would have all gone a lot more smoothly if the actual defaults were changed (and documented) instead of inventing convoluted solutions to sometimes, maybe change certain settings. It would be both more discoverable and follow the standard behavior that people expect when it comes to overriding the defaults.
James McCoy
Are there some things that should be removed from the system vimrc that distributions use? Probably, but there are also things that can't be removed.
If there were an alternative mechanism for distributions to provide the functionality they need, that would also avoid the need to provide a system vimrc. That won't prevent admins from using that functionality, though, which would run into the exact same problem of their settings being overridden when they upgrade to Vim 8.
Tommy Allen
It's not nice to change it now, since it's been like this for a while.
The time that has passed since 7.4.2111 is insignificant when measured up against Vim's history and foreseeable future. But, it grows more significant with each day that passes without a fix.
All these problems won't exist if there is no /etc/vimrc. Just use the Vim defaults, which are documented and the same on all systems.
If these defaults override any configuration file, regardless of how much you dislike them, then they are not defaults and the system is broken. The true defaults are set from the start and overridden by configs.
There is no reason Vim should work different on debian/ubuntu/suse or whatever distribution, just because some maintainer has a different idea about what defaults to use and enforce this upon all their users.
Let users debate this with their respective distro's maintainers and free yourself from the burden of caring. Just don't allow something that's broken to continue being broken because you think people expect it to remain broken.
Uwe Sauter
I too have to add my complaints to this topic.
Configuration files exist to override default settings system-wide (/etc/vimrc) or on a per user case (~/.vimrc) and not to be overridden by the defaults.
What is the official proposed way to benefit from all the defaults but customize just those that annoy you (like mouse=a that totally blows the way I work with selecting/pasting with the middle button)? Just putting set mouse=v into /etc/vimrc or ~/.vimrc totally turns off every other option that might acutally be useful…