[vim/vim] Always load defaults.vim (PR #14883)

Christian Brabandt

unread,

May 31, 2024, 6:15:33 AM5/31/24

to vim/vim, Subscribed

Always since the introduction of defaults.vim is has been controversial how Vim loaded those defaults (because they were not loaded when a custom user vimrc file was present).

This is an attempt to solve this, by always sourcing the defaults.vim file. This is unfortunately not fully backwards compatible, since now new settings may be setup before you source your vimrc file. So if you relied on some settings that have been changed in defaults.vim you will now have to undo those changes in your vimrc, or opt-out explicitly from sourcing the defaults.vim. This is possible by setting the VIM_NO_SOURCE_DEFAULTS environment variable, which will keep the current load-order.

I have also slightly changed 2 more options in defaults.vim, one removing the 'i' flag from the 'complete' setting as requested in #14853 and another is setting the '!' flag for Windows, so that external commands are run in a terminal and not an ugly cmdline window.

Currently marked as draft, please let me know if you think this is beneficial for Vim or your rather would like to keep the existing behaviour and not change it again.

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/14883

Commit Summary

490740d update defaults.vim
4d958ee Always load defaults.vim

File Changes

(4 files)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

May 31, 2024, 6:58:06 AM5/31/24

to vim/vim, Subscribed

there always some people specially new comings jumped out, say: 'Hi, I like to full-feat my vim to act like a IDE',
which like some xxxvim does (yea, i knew someone probably jumped out say: "you were a 'gatekeeper'.." again :lol:).

but that's not the official vim is;
or if you really like some defaults (well, mostly difficult to get common agreement), you can try 'vim --clean',
that will auto load 'defaults.vim' already, and your specific vimrc can based on that.

// to be clear: i donot like such auto-load defaults start, this will be a break again.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jun 2, 2024, 2:00:43 PM6/2/24

to vim/vim, Subscribed

@vim/admins any opinion on this one please?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian J. Robinson

unread,

Jun 2, 2024, 2:31:07 PM6/2/24

to vim/vim, Subscribed

I implore you not to do this. It will cause more problems than it solves, in my opinion.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

vim-dev ML

unread,

Jun 2, 2024, 3:53:11 PM6/2/24

to vim/vim, vim-dev ML, Your activity

On Sun, Jun 2, 2024 at 11:00 AM Christian Brabandt <
***@***.***> wrote:

> @vim/admins <https://github.com/orgs/vim/teams/admins> any opinion on
> this one please?
>
>
>
In my opinion, the addition of defaults.vim caused more problems that it
solved. I think we
should not make sourcing defaults.vim the default.

Regards,
Yegappan

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

James McCoy

unread,

Jun 2, 2024, 7:07:03 PM6/2/24

to vim/vim, vim-dev ML, Comment

@jamessan commented on this pull request.

In src/main.c:

>  	if (process_env((char_u *)"VIMINIT", TRUE) != OK)
 	{
+	    if (mch_getenv("VIM_NO_SOURCE_DEFAULTS") == NULL)

If it's going to be unconditionally loaded, it seems like it should happen before the system vimrc so the typical "defaults can be overridden by system config which can be overridden by user config" pattern is followed.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

James McCoy

unread,

Jun 2, 2024, 7:14:10 PM6/2/24

to vim/vim, vim-dev ML, Comment

@jamessan commented on this pull request.

On runtime/defaults.vim:

There's an exists('skip_defaults_vim') check on line 19 which doesn't make as much sense now. Maybe replace that with a $VIM_NO_SOURCE_DEFAULTS check?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

James McCoy

unread,

Jun 2, 2024, 7:20:31 PM6/2/24

to vim/vim, vim-dev ML, Comment

In my opinion, the addition of defaults.vim caused more problems that it solved.

In my experience, that was due to both the new defaults and the break from Vim's previous precedence for configuration. Defaults.vim was sourced by default, unless you had a vimrc, but only a user vimrc not a system vimrc. Some people on single user systems use the system vimrc, rather than a per-user one, so now they had to learn new mechanisms to override Vim's behavior because the "defaults" were being applied after their normal configuration.

Fixing these inconsistencies both makes it easier for users to be introduced to new behavior as well as making it easier for users to opt out if they don't like it.

Yes, this is an incompatible change from the behavior of the past ~8 years, but it aligns better to the behavior of the previous ~20 years in regards to the precedence of configuration.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Maxim Kim

unread,

Jun 2, 2024, 7:26:54 PM6/2/24

to vim/vim, vim-dev ML, Comment

In my opinion, the addition of defaults.vim caused more problems that it solved. I think we should not make sourcing defaults.vim the default. Regards, Yegappan

Agree here, breaking change as well, but I would not source defaults.vim at all.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jun 3, 2024, 2:29:54 AM6/3/24

to vim/vim, vim-dev ML, Comment

thanks putting on hold then, seems too controversial

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

dundargoc

unread,

Jun 3, 2024, 5:39:24 AM6/3/24

to vim/vim, vim-dev ML, Comment

thanks putting on hold then, seems too controversial

Is removing defaults.vim not an option then? As far as I can see no one seems to be a fan of defaults.vim as it is currently used today anyway. IMO the current situation is the worse than either always loading it or removing it entirely, as it leads to the problem @jamessan described. Yes, it is technically a breaking change, but only for new users without a .vimrc in which case the current behavior is already jarring/breaking as they'd lose all configuration from defaults.vim upon creating a .vimrc.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Clason

unread,

Jun 3, 2024, 6:14:54 AM6/3/24

to vim/vim, vim-dev ML, Comment

You could move it to pack/dist/opt so that users can source it with a single command. I don't know what the best way would be to signal new users that they might wish to do so, though. Maybe in the intro message if no/empty user .vimrc is detected?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Aliaksei Budavei

unread,

Jun 3, 2024, 4:36:32 PM6/3/24

to vim/vim, vim-dev ML, Comment

The distributed runtime/vimrc_example.vim already sources
defaults.vim and this fact is documented. Users that care
to follow its evolution can already do so when they use that
example file to write their own vimrc. If they decide to
write this configuration file from scratch, chances are they
have been made aware of defaults.vim from reading parts of
starting.txt etc., and will copy what they depend on from
defaults.vim (or keep sourcing it). What further guidance
do they need?

Having an environment variable (and :h skip_defaults_vim)
as a means to opt out may still frustrate GVim users wishing
to opt out, who may meet environment variables for the first
time, be unaware how can these be persisted across launches
of Vim, be likely forced to fiddle with launcher recipes
(e.g. *.desktop) and struggle to get rid of the cached
version of that recipe without having to log out or reboot.
Perhaps, Vim can first look for, say ~/.vim/defaults.vim,
and source only it, if readable, and only bother sourcing
$VIMRUNTIME/defaults.vim otherwise, and later look for
vimrc. So that creating an empty defaults.vim will also
achieve the opt-out effect.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Luca Saccarola

unread,

Jun 22, 2024, 10:04:55 AM6/22/24

to vim/vim, vim-dev ML, Comment

Personally, at this point, I would just never source it. Things like this should be done 100% or 0% not this weird in between we have going on.

From what I can see really nobody likes the current behavior.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Luca Saccarola

unread,

Sep 4, 2024, 4:55:11 PM9/4/24

to vim/vim, vim-dev ML, Comment

I've created a poll to see what people think #15625.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Romain Lafourcade

unread,

Nov 30, 2024, 2:30:29 AM11/30/24

to vim/vim, vim-dev ML, Comment

Please remove defaults.vim entirely.

The main problem with that scheme is that it certainly improves the user experience for casual users without personal config, but creating a vimrc, which is the first step toward customization, effectively disables all the sensible defaults. The user is left in the dark because, while they certainly could do what is suggested under :help defaults.vim to get their sensible defaults back… they had no idea they were using defaults.vim in the first place, so they are left in the dark.

So yes, casual users certainly get a better first experience, but diving in became more frustrating.

Before that feature was implemented I suggested a simpler, probably naive, scheme:

If the program was called as vi, assume the user expects the barebones experience and give them the equivalent of vim -u NONE, with compatible and all.
- And eventually source *rc files relevant to vi (.exrc, others?), ignoring all or most of $VIMRUNTIME.
If the program was called as vim (including vimdiff, etc.), assume the user expects the improved experience and give them "modern" settings by default, starting with nocompatible. Not via something like defaults.vim but via actually useful default values.
- And eventually source *rc files and other runtime files relevant to vim.

In other words: have two paths, one for vi with very few features enabled by default, and one for vim with more useful defaults: set nocompatible, syntax on, filetype plugin indent on, set laststatus=2, etc.

Casual users and ultra hardcore grey beards who do $ vi foobar.txt get exactly what they expect, with all the cool stuff only a :set away.

Vim-curious users who want to "dig in" can create ~/.vimrc without losing syntax highlighting, etc.

Experienced vimmers with their own vimrc experience no change.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Luca Saccarola

unread,

Nov 30, 2024, 4:39:53 AM11/30/24

to vim/vim, vim-dev ML, Comment

@romainl it is exactly why we are trying gradually to move this defaults into the C core. Unfortunately it is a slow process because there is a lot of backlash (see #16055). But I 100% agree. I find so frustrating trying to help my friends learning vim and they are gotched by this all the time.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Romain Lafourcade

unread,

Nov 30, 2024, 5:54:30 AM11/30/24

to vim/vim, vim-dev ML, Comment

@saccarosium part of that backlash is due to the content of defaults.vim being all over the place. It tries to do too much and I can very well understand the worries about moving defaults.vim as a whole into the core. Moving some of it, on the other hand…

Some of it could probably be moved into the core without anyone noticing, like history, ttimeout, ttimeoutlen, display, guioptions, syntax, and maybe mouse.

Other things like wildmenu or the mappings, are potentially more intrusive and should probably be forgotten.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Luca Saccarola

unread,

Nov 30, 2024, 8:22:03 AM11/30/24

to vim/vim, vim-dev ML, Comment

It tries to do too much and I can very well understand the worries about moving defaults.vim as a whole into the core.

Yes, I know. Most of the things we are trying to move are functional thing. For example we increased the history (#16057)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Enno

unread,

Dec 14, 2024, 5:54:22 PM12/14/24

to vim/vim, vim-dev ML, Comment

Regarding @romainl 's suggestion to start Vim

as vim -u NONE with compatible when called as vi (and maybe non-interactively?), and
with "modern" settings by default with nocompatible when called as vim

a possible preventive against surprising those who type vim and whose settings would change by the new defaults (with the example of disabled indenting cited in the mailing list), could be to ask them, for each setting with a new default not set in the vimrc (if found), to make these diverging settings explicit in their vimrc:
For a while by a prior notification while keeping the old defaults, and then (by a one-time confirmation prompt!?) after having changed to the new defaults.

Since most veterans will have agreed on those new defaults (that's how they came to be), this would affect few (during one Vim version jump).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Maxence Weynans

unread,

Jan 28, 2025, 2:11:57 PM1/28/25

to vim/vim, vim-dev ML, Comment

@romainl 's take on the issue is the correct one.

Still, we cannot ignore the fact that if most of the settings in defaults.vim are for the most part sensible ones, there are some that completely break the principle of least surprise, even to this day (downstream propagation takes years), and in ways that are mostly inscrutable for the average user.

Unfortunately, this is where Bram's disregard for any sort of larger scale context than an isolated end user comes back to haunt us.

For example, we have thousands of unix boxes at work. Downstream takes years. A few hundreds of them are now exhibiting what my coworkers, and some customers, consider to be downright bizarre behaviour.
I am currently researching various ways of overriding defaults.vim, because we provide the option for a variety of linux distros, and I cannot assume that a single method will work everywhere.

I don't expect the older machines to be phased out any time soon.
I don't expect defaults.vim to actually be the default config for at least 5 more years.

Among the things that are broken as of today :
set scrolloff=5 breaks L, M and H.
The "new" behaviour is technically correct. Yet, it is unacceptable.

set mouse=a is effectively russian roulette. Yes, there are ways to work around it, but the lack of predictability of the interactions between the feature, ssh x11 forwarding, and the user's environment cannot be ignored.

I believe visual selections in the context of remote ssh sessions, in which vim cannot infer the background color and hence sets background=light are still broken, specifically because said the light default colorscheme is not background agnostic, as it should always have been. This may have been fixed in ways I'm currently unaware of.
What I consider to be rushed and short-sighted handling by @chrisbra of some of the issues listed in this issue in the colorschemes repo has, quite frankly, put me off from working on this subject for a long time, although I'd be willing to get back to it.

I understand that the time to ditch defaults.vim was 7 or 8 years ago.
Yet, I believe that defaults.vim has had very little impact on single-user machines,where custom configs are the most common, and has been nothing but a nuisance on multi-user machines.

We can still fix it, so the default behaviour dowstream eventually makes sense.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jan 29, 2025, 4:27:39 AM1/29/25

to vim/vim, vim-dev ML, Comment

Sorry I don't get it, there were some complains in vim/colorschemes#250 about the default Visual highlighting and I have attempted to improve this in #13663 and after the feedback I received it was merged. And now you complain that this was "short-sighted handling" ? So why did you not provide feedback to #13663 after all?

Regarding the defaults.vim handling, I don't intend to touch it further. Whatever I do people will complain, like you did here.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Romain Lafourcade

unread,

Jan 29, 2025, 5:05:22 AM1/29/25

to vim/vim, vim-dev ML, Comment

defaults.vim was a bad idea years ago but, after so many years, it will understandably (but frustratingly) be hard to root out.

The plan to move the least problematic settings into the core is IMO a good move as it will slim down defaults.vim without negatively affecting those who depend on those settings. More beneficial aspects:

easier for users who want to dive in to start writing their own vimrc,
simplified doc (no "set to XXX in defaults.vim" anymore.

But that leaves all the wacky ones, like scrolloff or the mappings. Newcomers are and will be tripped up by those when they decide to dive in because, again, they have absolutely no idea that they even exist, or can be overridden, or that they come from a hidden defaults.vim, etc. They are "defaults" that are not actually defaults, which is very weird when you create your vimrc and Vim starts behaving strangely. And they are very frustrating for your casual sysadmin who depends on stock vi/Vim.

What if there was a middle road, where defaults.vim is slimmed down but still there with all its supposedly user-friendly stuff AND the user is given more transparency and leverage?

What if, instead of being buried in the doc, the mention of defaults.vim and most importantly how to nuke it was made more prominent? Maybe a message, like "We have made Vim more usable for you, yadda yadda. See :help defaults.vim" shown at startup? Or a mention in the intro text when you start Vim without a filename?

What if it was possible to disable defaults.vim with a flag like --no-defaults? Or an environment variable like $VIM_NO_DEFAULTS?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Enno

unread,

Jan 29, 2025, 5:25:22 AM1/29/25

to vim/vim, vim-dev ML, Comment

Whatever I do people will complain, like you did here.

It's a quandary, though besides minimizing the number of people complaining at one point (say by asking longtime users to adapt to typing vi), in the long run more important could be maximizing the number of people finding use in Vim (say by being more welcoming to new users with more predictable modern defaults).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Enno

unread,

Jan 29, 2025, 5:26:25 AM1/29/25

to vim/vim, vim-dev ML, Comment

I might have been paraphrasing @neutaaaaan 's

Unfortunately, this is where Bram's disregard for any sort of larger scale context than an isolated end user comes back to haunt us.

—

Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Tony Mechelynck

unread,

Jan 29, 2025, 9:05:26 AM1/29/25

to vim...@googlegroups.com, reply+ACY5DGEF45U3JJRTI3...@reply.github.com, vim/vim, vim-dev ML, Comment

I notice three kinds of answers in this thread :

• Always use defaults.vim regardless of whether there is a vimrc.

• Never use defaults.vim, i.e. go back to prehistory when even vimrc_example.vim didn't exist.

• Use defaults.vim by default when no vimrc is found, unless it is explicitly disabled by a command-line argument. Users wanting to use it (and possibly tweak it) together with a vimrc should source defaults.vim (or vimrc_example.vim) somewhere near the top of their vimrc, then override later in their vimrc whatever it may be that the defaults.vim sets and they don't want.

IMHO both of the former are too high-handed, not backward-compatible, and break the principle of least surprise, at least for seasoned users. If the first option is used I would have to transfer to a "system vimrc" the few settings which are now set in my vimrc before I source the vimrc_example.vim. If the second option is used I would have to write either write explicitly in my vimrc all the (many) settings which I now import from (essentially) the defaults.vim, or copy the defauts.vim to ~/.vim/ before it disappears and source that instead. I like neither of these. The third possibility is IIUC what we already have.

Best regards,

Tony.

vim-dev ML

unread,

Jan 29, 2025, 9:06:02 AM1/29/25

to vim/vim, vim-dev ML, Your activity

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.

Maxence Weynans

unread,

Jan 29, 2025, 11:33:55 AM1/29/25

to vim/vim, vim-dev ML, Comment

@chrisbra I might be wrong, and if so I apologize, but I do remember your initial tweak to visual selections being pushed in 9.1.000 and not working properly in some contexts, because you moved to address the issue too fast. Given how most linux distros pull from upstream (major/minor version + CVEs), I assume this is still problematic on production machines.

Any modification we make to defaults.vim will be a breaking change.
This doesn't mean that fixing inconsistent or effectively unpredictable behaviour isn't worth it.
Complaining that no matter what you do, people will complain, is exactly what Bram did, and even he eventually backpedalled with the bizarre hack that allows a systemwide config to somehow ignore defaults.vim after loading it according to `:scriptnames:.
The core of the issue isn't even the config itself, but a lack of awareness of how it impacts real-life production environments, as opposed to single user machines. This, is still worth fixing.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Christian Brabandt

unread,

Jan 29, 2025, 12:10:58 PM1/29/25

to vim/vim, vim-dev ML, Comment

This doesn't mean that fixing inconsistent or effectively unpredictable behaviour isn't worth it.

I tried to gradually fix it by moving non-controversial changes to the C core. Still there was back pressure from the community. So much that I am feeling exhausted trying to fix things.

Even trying to make it more consistent and always load it (what this PR here is doing) is causing too much distraction for people, that I don't feel it worth to annoy people (who are no used to the "bizare default options") a second time by fixing things and have those people now require to adjust/undo the changes in their $MYVIMRC file (which they don't have to do right now, because they never set them in the first place, like the scrolloff or mouse feature).

What if it was possible to disable defaults.vim with a flag like --no-defaults? Or an environment variable like $VIM_NO_DEFAULTS?

You mean like always sourcing it but skip loading it if this Environment variable exists / additional argument is passed? Not sure if throwing additional complexity at the problem helps in the first place.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

D. Ben Knoble

unread,

Jan 29, 2025, 2:30:00 PM1/29/25

to vim/vim, vim-dev ML, Comment

Reminders?

We are pretty much all volunteers
We are working towards a common goal of improving vi (Vim!)
We are all doing the best we can with what we have
Burning out maintainers kills projects; conversely, delightful interactions can help buoy support.

Christian, if there’s not already a list: what can any of us do to lift burden off your shoulders? Issue/PR triage? Find a way to share responsibility for all the complaints? …?

I admire your attempt to steer the project and am dumbfounded that you continue to find the energy. We are all doing the best we can with what we have.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Christian Brabandt

unread,

Jan 30, 2025, 6:01:32 AM1/30/25

to vim/vim, vim-dev ML, Comment

Thanks @benknoble for the headsup! Let's try to avoid endless fruitless discussions. I am also thinking to document what we can expect from Vim development. Something like a mission statement, that we will try to avoid making backwards incompatible changes, yet such things can happen while merging stuff into master but we will try to fix this if this happens.

@romainl / @romainl-rzf (not sure who is the correct one):

How about the following path forwards:

Keep the current defaults.vim behaviour (e.g. not being sourced when a vimrc file is found)
provide a --no-load-defaults option to skip loading defaults.vim always (possibly in conjunction with "export VIM_NO_DEFAULTS=1`)
provide a --load-defaults option to always load defaults.vim

This way,

new people to Vim, come into the "benefit" of defaults.vim
new people starting to configure Vim, can use --load-defaults to have the benefit of defaults.vim + plus there additional custom configuration. This can be aliased in $SHELL so they don't have to type it, or they use the already documented approach to source it manually in $MYVIMRC.
experienced Vimmers can continue to use their $MYVIMRC file without being bothered by the changes in defaults.vim
SysAdmin Users that need to jump on different machines can opt-out of defaults.vim by using the --no-load-defaults option, or export that environment variable and be done with this.
it doesn't add more surprises, but give additional flexibility (once they have read the documentation of course).

This should give all people a choice on how (not) to use defaults.vim. Anthing against this (except for the additional complexity)?

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

D. Ben Knoble

unread,

Jan 30, 2025, 6:37:18 AM1/30/25

to vim/vim, vim-dev ML, Comment

Thanks @benknoble for the headsup! Let's try to avoid endless fruitless discussions.

Yes! Someone (or group) needs to be willing to summarize, decide, and act. You've done that so far, and we ought to be grateful even if we disagree, I think 😅

I am also thinking to document what we can expect from Vim development. Something like a mission statement, that we will try to avoid making backwards incompatible changes, yet such things can happen while merging stuff into master but we will try to fix this if this happens.

I look forward to it!

--%< a bunch of stuff about defaults %<--

I think creating choices might work; I agree that "visibility" of what choice is in effect (automatically or on-request) matters to helping users (new and experienced alike) discover the meaning of those choices.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Romain Lafourcade

unread,

Jan 30, 2025, 9:30:22 AM1/30/25

to vim/vim, vim-dev ML, Comment

@romainl / @romainl-rzf (not sure who is the correct one):

Both point to the same person (I think) but @romainl is the correct one. The other is for work, sorry for the confusion.

Keep the current defaults.vim behaviour (e.g. not being sourced when a vimrc file is found)

provide a --no-load-defaults option to skip loading defaults.vim always (possibly in conjunction with "export VIM_NO_DEFAULTS=1)

provide a --load-defaults option to always load defaults.vim

This looks like a step in the right direction to me. But I would like to remind everyone that "make Vim more comfortable for the new/casual user" is an old problem, the most extreme form of which has already been solved in the past… and in a much less intrusive way, by adding the -y option and the evim alias.

The funny thing is that $VIMRUNTIME/defaults.vim ended up being bigger in size than $VIMRUNTIME/evim.vim despite solving a less extreme problem. They actually share quite a few lines, even.

Hiding defaults.vim behind a flag, just like what is already been done for evim.vim, would solve all the issues caused to existing users by the current scheme. You do $ vim foobar and you get what you are used to, end of the story.

The myopic focus on "new users" is the real problem, here. Vim has lots and lots of existing users, and many of them actually rely on it to act like old vi out of the box. Messing with those real existing users in the name of helping hypothetical/imaginary/future new users was, is, and will forever be a stupid idea. Satisfying the few over the many as never been a good strategy, especially when those few are imaginary. Like we say in French: "un tiens vaut mieux que deux tu-l'auras".

So, this would be my recommendation…

Put whatever you want in defaults.vim and/or evim.vim to solve whatever hypothetical problems imaginary future users might have with the real "defaults".
Hide it behind a flag to make sure that real existing users are not impacted.
Keep on gradually improving the real "defaults" that can be changed without too much troubles, like history, etc.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.

Romain Lafourcade

unread,

Jan 30, 2025, 9:31:09 AM1/30/25

to vim/vim, vim-dev ML, Comment

You are receiving this because you commented.

Christian Brabandt

unread,

May 10, 2025, 2:26:07 PM5/10/25

to vim/vim, vim-dev ML, Push

@chrisbra pushed 1 commit.

efc567d Update defaults.vim handling

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

May 10, 2025, 2:31:41 PM5/10/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

Okay, so I reworked the whole thing. Now it does not change the default settings. However, users can now use --load-defaults to always load defaults.vim and --no-load-defaults to always skip loading defaults.vim. Alternatively, if $VIM_NO_SOURCE_DEFAULTS is defined, Vim will skip loading defaults.vim, however this can be overwritten using those arguments.

Note: when using --load-defaults, the order of the sourced runtime files is different and defaults.vim will always be loaded first. This is so that the effect can be undoing using either the system vimrc file or the users vimrc file.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Christian Brabandt

unread,

May 10, 2025, 2:43:03 PM5/10/25

to vim/vim, vim-dev ML, Push

@chrisbra pushed 1 commit.

8901206 Update defaults.vim handling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

May 10, 2025, 2:48:54 PM5/10/25

to vim/vim, vim-dev ML, Comment

@benknoble commented on this pull request.

In runtime/doc/starting.txt:

> @@ -840,8 +847,12 @@ accordingly.  Vim proceeds in this order:
 							*evim.vim*
      a. If Vim was started as |evim| or |eview| or with the |-y| argument, the
 	script $VIMRUNTIME/evim.vim will be loaded.
+
+     b. If Vim was started using the |--load-defaults| argument |defaults.vim|

Should this get a helptag like the other items?

In runtime/doc/starting.txt:

> +This should work well for new Vim users.  If you create your own .vimrc,
+defaults.vim will always be loaded before your own .vimrc, so that you
+can revert settings that have been set. If you don't like some of the
+defaults, you can still source defaults.vim and revert individual settings.
+See the defaults.vim file for hints on how to revert each item.  See
+|:scriptnames| to verify which runtime files have been loaded.

Ok, so the new pattern for users with a vimrc but who don't want to source defaults.vim is effectively to export VIM_NO_SOURCE_DEFAULTS? I think I can live with that, but I also think we're going to see some surprised folks when defaults.vim starts getting sourced even for folks with vimrcs. (I can live with that, too, but YMMV.)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

John M Devin

unread,

May 10, 2025, 4:42:39 PM5/10/25

to vim/vim, vim-dev ML, Comment

jmdevin left a comment (vim/vim#14883)

I've had some thoughts on this for a while that I haven't put down in any organized fashion, but one piece is worth mentioning. As a note if anyone is unaware, vim has (partially) added support for the XDG Base Directory Spec, which right now includes loading ~/.config/vim/vimrc, if no ~/.vimrc or ~/.vim/vimrc exist.

This is a feature that I think would be appropriate with vim's next major version, so vim10 most likely:

Allow the user to create a file ~/.config/vim/config.vim, (or $XDGwhatever/vim/config.vim).
When found (possibly only if no vimrc was found?), this file would serve as the users vimrc. It would also have the effect of causing vim to use newer default option settings than those that existed in previous vim versions, without needing to explicitly load defaults.vim.

This eliminates the problem that current users creating a vimrc for the first time have, where defaults.vim is suddenly not loaded anymore and the behavior changes even with an empty file. It also eliminates the problem where any default option change upsets someone, no matter what. Creating a ~/.config/vim/config.vim file is an explicit opt-in to having the defaults changed to be sane. Anyone using a vimrc file would keep the same option settings, even when updating to a new version. Sourcing or not sourcing defaults.vim by default doesn't solve this problem; it just means changing defaults.vim causes the same argument.

There are many, many other ideas that can branch off this one. I like the --load-defaults cli flag. Maybe, and I know this is a big idea, it would be appropriate for a new command to invoke vim? The same way that vim is used now so that vi can be invoked with vi compatibility, maybe vin could invoke vim with updated options, even if no new config.vim file is found? How does viNext sound as a mnemonic?

Again, I know this is a big idea, but I'm fairly certain vim10 is a ways off. Introducing a way for vim's defaults to continue to be improved without upsetting half the current user base every commit seems like a good idea.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Maxim Kim

unread,

May 10, 2025, 11:29:36 PM5/10/25

to vim/vim, vim-dev ML, Comment

@habamax commented on this pull request.

In runtime/doc/starting.txt:

> +This should work well for new Vim users.  If you create your own .vimrc,
+defaults.vim will always be loaded before your own .vimrc, so that you
+can revert settings that have been set. If you don't like some of the
+defaults, you can still source defaults.vim and revert individual settings.
+See the defaults.vim file for hints on how to revert each item.  See
+|:scriptnames| to verify which runtime files have been loaded.

I think I can live with that, but I also think we're going to see some surprised folks when defaults.vim starts getting sourced even for folks with vimrcs.

Indeed. Would be annoying. Especially if I wouldn't be able to use

" Bail out if something that ran earlier, e.g. a system wide vimrc, does not
" want Vim to use these default values.
if exists('skip_defaults_vim')
  finish
endif

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Maxim Kim

unread,

May 10, 2025, 11:48:29 PM5/10/25

to vim/vim, vim-dev ML, Comment

@habamax commented on this pull request.

In runtime/doc/starting.txt:

> +This should work well for new Vim users.  If you create your own .vimrc,
+defaults.vim will always be loaded before your own .vimrc, so that you
+can revert settings that have been set. If you don't like some of the
+defaults, you can still source defaults.vim and revert individual settings.
+See the defaults.vim file for hints on how to revert each item.  See
+|:scriptnames| to verify which runtime files have been loaded.

I mean, I would be able to turn off or revert all the autocommands, mappings and settings coming from defaults.vim I don't like.

It is just the whole idea of defaults.vim seems broken to me. But I can leave with it as @benknoble stated.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

May 11, 2025, 7:29:11 AM5/11/25

to vim/vim, vim-dev ML, Comment

@chrisbra commented on this pull request.

In runtime/doc/starting.txt:

> +This should work well for new Vim users.  If you create your own .vimrc,
+defaults.vim will always be loaded before your own .vimrc, so that you
+can revert settings that have been set. If you don't like some of the
+defaults, you can still source defaults.vim and revert individual settings.
+See the defaults.vim file for hints on how to revert each item.  See
+|:scriptnames| to verify which runtime files have been loaded.

but this would only happen if you do it intenationally by the means of --load-defaults. So should be okay, no?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Maxim Kim

unread,

May 11, 2025, 7:45:50 AM5/11/25

to vim/vim, vim-dev ML, Comment

@habamax commented on this pull request.

In runtime/doc/starting.txt:

> +This should work well for new Vim users.  If you create your own .vimrc,
+defaults.vim will always be loaded before your own .vimrc, so that you
+can revert settings that have been set. If you don't like some of the
+defaults, you can still source defaults.vim and revert individual settings.
+See the defaults.vim file for hints on how to revert each item.  See
+|:scriptnames| to verify which runtime files have been loaded.

Oh, it was not clear from the description. So defaults would not be loaded unless --load-defaults are provided?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

May 11, 2025, 7:56:48 AM5/11/25

to vim/vim, vim-dev ML, Push

@chrisbra pushed 1 commit.

5dab048 Update defaults.vim handling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

May 11, 2025, 8:40:47 AM5/11/25

to vim/vim, vim-dev ML, Comment

@chrisbra commented on this pull request.

In runtime/doc/starting.txt:

> +This should work well for new Vim users.  If you create your own .vimrc,
+defaults.vim will always be loaded before your own .vimrc, so that you
+can revert settings that have been set. If you don't like some of the
+defaults, you can still source defaults.vim and revert individual settings.
+See the defaults.vim file for hints on how to revert each item.  See
+|:scriptnames| to verify which runtime files have been loaded.

yes, let me update that part of the documentation

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

May 11, 2025, 9:13:00 AM5/11/25

to vim/vim, vim-dev ML, Push

@chrisbra pushed 1 commit.

1924158 Update defaults.vim handling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

May 12, 2025, 11:43:14 AM5/12/25

to vim/vim, vim-dev ML, Comment

@benknoble commented on this pull request.

In runtime/doc/starting.txt:

> +This should work well for new Vim users.  If you create your own .vimrc,
+defaults.vim will always be loaded before your own .vimrc, so that you
+can revert settings that have been set. If you don't like some of the
+defaults, you can still source defaults.vim and revert individual settings.
+See the defaults.vim file for hints on how to revert each item.  See
+|:scriptnames| to verify which runtime files have been loaded.

I can't "mark resolved" here, just FYI, so someone else will have to.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

May 22, 2025, 1:26:21 PM5/22/25

to vim/vim, vim-dev ML, Comment

Shane-XB-Qian left a comment (vim/vim#14883)

> but this would only happen if you do it intenationally by the means of `--load-defaults`. So should be okay, no? what's the difference with `--clean` as i said it earlier in this ticket? if someone do like to load defaults.vim, he can run vim as `vim --clean`, tho `--load-defaults` maybe a more specific name. // anyway, please keep `g:skip_defaults_vim` can be able to override it. -- shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

May 22, 2025, 3:18:15 PM5/22/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

what's the difference with --clean as i said it earlier in this ticket?
if someone do like to load defaults.vim, he can run vim as vim --clean,

tho --load-defaults maybe a more specific name.

The difference is, --load-defaults will always load defaults and not skip loading your personal vimrc file.

// anyway, please keep g:skip_defaults_vim can be able to override it.

That behaviour does not change

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

May 22, 2025, 4:04:31 PM5/22/25

to vim/vim, vim-dev ML, Comment

Shane-XB-Qian left a comment (vim/vim#14883)

but g:skip_defaults_vim is registered at vimrc, how it work? to me, i have a simple alias: vim --clean -S xxx.vim seems like that (i am typing in the mail), then no any argue~ -- shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

May 22, 2025, 4:09:18 PM5/22/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

but g:skip_defaults_vim is registered at vimrc, how it work?

That is too late then. Don't use --load-defaults if you don't want it to be loaded.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

May 22, 2025, 4:11:07 PM5/22/25

to vim/vim, vim-dev ML, Comment

Shane-XB-Qian left a comment (vim/vim#14883)

or you may assume they donot expect g:skip_defaults_vim work as if passed --load-defaults? ok, if yes then... -- shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Damien Lejay

unread,

Jun 27, 2025, 5:22:04 PM6/27/25

to vim/vim, vim-dev ML, Comment

dlejay left a comment (vim/vim#14883)

I independently arrived at the same theoretical conclusion as @romainl

Iʼll add that today the situation of POSIX compliance regarding vi is not great.

macOS used to be the most commonly used UNIX® in the world. But today, vi on macOS is a link to vim that comes with an SIP protected vimrc with set nocompatible.

On Linux, it is common to have vi also be just vim. If vim is the tiny version, then the defaults are not loaded so, it works.
As soon as you apt install vim (for a Debian example), then vi stops behaving like the POSIX documentation says. Installing a text editor brakes POSIX ‽

When a user types vi on a POSIX system, they should reliably get VI-like behaviour. As it is set in stone forever.

The big question : is providing a POSIX-compliant implementation of vi one of the goals of Vim ?

What is the vision for Vim ?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Christian Brabandt

unread,

Jun 28, 2025, 2:37:56 PM6/28/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

The big question : is providing a POSIX-compliant implementation of vi one of the goals of Vim ?

Yes, a POSIX compliant version is still a goal of this project. That's what we have the vim.tiny version for.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.

Damien Lejay

unread,

Jun 29, 2025, 4:10:27 AM6/29/25

to vim/vim, vim-dev ML, Comment

dlejay left a comment (vim/vim#14883)

Yes, a POSIX compliant version is still a goal of this project. That's what we have the vim.tiny version for.

I suggest writing it somewhere in the main README.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Christian Brabandt

unread,

Jun 29, 2025, 12:30:30 PM6/29/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

I suggest writing it somewhere in the main README.

2bfd1ee

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jul 9, 2025, 2:24:44 PM7/9/25

to vim/vim, vim-dev ML, Push

@chrisbra pushed 1 commit.

783b237 Update defaults.vim handling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jul 10, 2025, 3:07:16 PM7/10/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

I know this has been a controversial topic from the beginning. I hope this PR helps everyone - both those who love defaults.vim and those who dislike it - by making it possible to always or never load it.

If anyone sees a reason why this PR should not be merged, please speak up now. Otherwise, I plan to merge it sometime next week.

Thanks!

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Gary Johnson

unread,

Jul 10, 2025, 9:18:27 PM7/10/25

to vim/vim, vim-dev ML, Comment

ghgary left a comment (vim/vim#14883)

Christian, would you please summarize the current state of this PR? I haven't followed all the discussion. My understanding is that the new strategy is that Vim will always source defaults.vim before any system or personal vimrc unless VIM_NO_SOURCE_DEFAULTS is set to some value other than 0. Is that correct?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Enno

unread,

Jul 11, 2025, 2:19:51 AM7/11/25

to vim/vim, vim-dev ML, Comment

@Konfekt commented on this pull request.

In runtime/doc/starting.txt:

> @@ -1077,31 +1088,36 @@ giving the mapping.
 
 Defaults without a .vimrc file ~
 							*defaults.vim* *E1187*
-If Vim is started normally and no user vimrc file is found, the
-$VIMRUNTIME/defaults.vim script is loaded.  This will set 'compatible' off,
-switch on syntax highlighting and a few more things.  See the script for
-details.  NOTE: this is done since Vim 8.0, not in Vim 7.4. (it was added in
-patch 7.4.2111 to be exact).
-
-This should work well for new Vim users.  If you create your own .vimrc, it is
-recommended to add these lines somewhere near the top: >
+If Vim is started normally, the $VIMRUNTIME/defaults.vim script is loaded.

Why was and no user vimrc file is found removed if in the next paragraph the same condition is set? Makes one wonder if it still applies or not.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jul 11, 2025, 2:55:58 AM7/11/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

Christian, would you please summarize the current state of this PR? I haven't followed all the discussion. My understanding is that the new strategy is that Vim will always source defaults.vim before any system or personal vimrc unless VIM_NO_SOURCE_DEFAULTS is set to some value other than 0. Is that correct?

The idea is, the following. By default Vim would not behave differently from how it currently behaves. That is, it will load defaults.vim if no user vimrc is found and will not source defaults.vim if it finds a user vimrc.

However what this PR adds in addition is that you can now control this behaviour. You don't want to load defaults.vim? So then use vim --no-load-defaults or set the environment variable: $VIM_NO_SOURCE_DEFAULTS.

You want defaults.vim loaded even when you have a user vimrc file? So then use vim --load-defaults. defaults.vim will however then be loaded a bit early, so that you can undo any changes in your own vimrc file.

An existing command line argument will override the environment variable.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jul 11, 2025, 2:56:41 AM7/11/25

to vim/vim, vim-dev ML, Comment

@chrisbra commented on this pull request.

In runtime/doc/starting.txt:

> @@ -1077,31 +1088,36 @@ giving the mapping.
 
 Defaults without a .vimrc file ~
 							*defaults.vim* *E1187*
-If Vim is started normally and no user vimrc file is found, the
-$VIMRUNTIME/defaults.vim script is loaded.  This will set 'compatible' off,
-switch on syntax highlighting and a few more things.  See the script for
-details.  NOTE: this is done since Vim 8.0, not in Vim 7.4. (it was added in
-patch 7.4.2111 to be exact).
-
-This should work well for new Vim users.  If you create your own .vimrc, it is
-recommended to add these lines somewhere near the top: >
+If Vim is started normally, the $VIMRUNTIME/defaults.vim script is loaded.

I'll fix this up. Should not be different to current behavior.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Damien Lejay

unread,

Jul 11, 2025, 3:01:12 AM7/11/25

to vim/vim, vim-dev ML, Comment

dlejay left a comment (vim/vim#14883)

If we take a step back and not look at the details, what does it mean for a project to implement something called NO_SOURCE_DEFAULTS ?

I would better understand a flag called VI_MODE.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Gary Johnson

unread,

Jul 11, 2025, 3:35:58 AM7/11/25

to vim/vim, vim-dev ML, Comment

ghgary left a comment (vim/vim#14883)

Then I don't understand how this improves the new-user experience. I thought the purpose of defaults.vim was to make Vim friendlier to the new user by setting options to values that were "better" than the real defaults. How on Earth is a new user supposed to know to use vim --load-defaults when they add their own vimrc? Not only that, but any other program that uses vim as its editor will invoke just vim, not vim --load-defaults, and the new user will again be left wondering what happened to the some of their option settings.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Enno

unread,

Jul 11, 2025, 3:38:02 AM7/11/25

to vim/vim, vim-dev ML, Comment

@Konfekt commented on this pull request.

In runtime/doc/starting.txt:

> -this. Alternatively, you can copy defaults.vim to your .vimrc and modify it
-(but then you won't get updates when it changes).
-
-If you don't like some of the defaults, you can still source defaults.vim and
-revert individual settings.  See the defaults.vim file for hints on how to
-revert each item.
+<
+See the defaults.vim file for hints on how to revert each item and see
+|:scriptnames| to verify which runtime files have been loaded.
+
+Note: since patch 9.1.XXXX Vim can be configured to force loading the
+|defaults.vim| runtime file as the very first initialization file using the
+|--load-defaults| option.  This is done, so the effects can be undo in the
+system and/or vimrc runtime file.  To prevent loading the |defaults.vim|
+runtime file, use the |--no-load-defaults| argument (or define the environment
+variable `$VIM_NO_SOURCE_DEFAULTS`).

For coherence either VIM_NO_LOAD_DEFAULTS or no-source-defaults?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Romain Lafourcade

unread,

Jul 11, 2025, 3:40:24 AM7/11/25

to vim/vim, vim-dev ML, Comment

romainl-rzf left a comment (vim/vim#14883)

If we take a step back and not look at the details, what does it mean for a project to implement something called NO_SOURCE_DEFAULTS ?

I would better understand a flag called VI_MODE.

I agree in principle. NO_SOURCE_DEFAULTS is the kind of name you would use internally but it is meaningless outside of the Vim context (distro, whatever…). But VI_MODE doesn't cut it either IMO. A more explicit name that includes VIM_ would be a lot better, like VIM_NO_SOURCE_DEFAULTS… which follows an established pattern, see :help $VIM_POSIX.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Christian Clason

unread,

Jul 11, 2025, 3:40:29 AM7/11/25

to vim/vim, vim-dev ML, Comment

@clason commented on this pull request.

In runtime/doc/starting.txt:

> -this. Alternatively, you can copy defaults.vim to your .vimrc and modify it
-(but then you won't get updates when it changes).
-
-If you don't like some of the defaults, you can still source defaults.vim and
-revert individual settings.  See the defaults.vim file for hints on how to
-revert each item.
+<
+See the defaults.vim file for hints on how to revert each item and see
+|:scriptnames| to verify which runtime files have been loaded.
+
+Note: since patch 9.1.XXXX Vim can be configured to force loading the
+|defaults.vim| runtime file as the very first initialization file using the
+|--load-defaults| option.  This is done, so the effects can be undo in the
+system and/or vimrc runtime file.  To prevent loading the |defaults.vim|
+runtime file, use the |--no-load-defaults| argument (or define the environment
+variable `$VIM_NO_SOURCE_DEFAULTS`).

And also $VIM_LOAD_DEFAULTS for symmetry (and to allow tools that start vim to partake in the default goodness).

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Christian Clason

unread,

Jul 11, 2025, 3:42:09 AM7/11/25

to vim/vim, vim-dev ML, Comment

clason left a comment (vim/vim#14883)

A more explicit name that includes VIM_ would be a lot better, like VIM_NO_SOURCE_DEFAULTS… which follows an established pattern, see :help $VIM_POSIX.

If you read @chrisbra's comment (or the actual code), you would see that this is exactly the name that is implemented.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Maxim Kim

unread,

Jul 11, 2025, 3:46:01 AM7/11/25

to vim/vim, vim-dev ML, Comment

habamax left a comment (vim/vim#14883)

I guess it is fine if we are 100% against breaking change. (Which I would go for: never automatically load defaults.vim, add info to :intro that users can add runtime defaults.vim to get some "new defaults" if they want to.)

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Romain Lafourcade

unread,

Jul 11, 2025, 3:47:10 AM7/11/25

to vim/vim, vim-dev ML, Comment

romainl-rzf left a comment (vim/vim#14883)

A more explicit name that includes VIM_ would be a lot better, like VIM_NO_SOURCE_DEFAULTS… which follows an established pattern, see :help $VIM_POSIX.

If you read @chrisbra's comment (or the actual code), you would see that this is exactly the name that is implemented.

Indeed, I only read the quoted message instead of the full thread/code. Sorry for the noise.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Gary Johnson

unread,

Jul 11, 2025, 4:07:35 AM7/11/25

to vim/vim, vim-dev ML, Comment

ghgary left a comment (vim/vim#14883)

Then I don't understand how this improves the new-user experience. I thought the purpose of defaults.vim was to make Vim friendlier to the new user by setting options to values that were "better" than the real defaults. How on Earth is a new user supposed to know to use vim --load-defaults when they add their own vimrc? Not only that, but any other program that uses vim as its editor will invoke just vim, not vim --load-defaults, and the new user will again be left wondering what happened to the some of their option settings.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Christian Brabandt

unread,

Jul 11, 2025, 7:53:40 AM7/11/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

Then I don't understand how this improves the new-user experience. I thought the purpose of defaults.vim was to make Vim friendlier to the new user by setting options to values that were "better" than the real defaults. How on Earth is a new user supposed to know to use vim --load-defaults when they add their own vimrc?

Well, we have conflicting goals here:

long time users should not be annoyed by loading defaults.vim and overriding some of their carefully crafted settings
new users should not start with a blank vi- or vim compatible, but get the benefits of a few of the more sophisticated options.

Now I could change the existing behaviour and annoy long-time users as well as new-users 🙈

Or I thought I can give users more control of whether or not defauls.vim will be loaded by providing a new command line switch. The idea being, once a new user starts configuring their own vimrc, they will read up the documentation and find that they either can source defaults.vim explicitly (this is already possible), or they can use the --load-defaults switch to make it explicit (and yes, may be I should also allow the use of $VIM_LOAD_DEFAULTS for symmetry).

Not only that, but any other program that uses vim as its editor will invoke just vim, not vim --load-defaults, and the new user will again be left wondering what happened to the some of their option settings.

Typically external programs have a way to configure $EDITOR. If I am not totally mis-remembing it, this is already possible for mutt, cron, visudo and git (usually via $EDITOR environment variable, although I am not completely sure it is allowed to configure arguments there), so that argument doesn't count. In fact you many git users already often complain that $EDITOR is different than their carefully crafted vim, just another reason to properly configure $TOOL.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Romain Lafourcade

unread,

Jul 11, 2025, 10:09:59 AM7/11/25

to vim/vim, vim-dev ML, Comment

romainl left a comment (vim/vim#14883)

That whole defaults.vim debacle must be reverted.

The core problem that made that scheme a failure is that there are not two but (at least) three broad categories of users to consider:

the prospective "new user",
the "existing user with carefully crafted settings",
the "existing user without carefully crafted settings".

The first category benefited from the change, that is until the point where they want to dive in and creating the mandatory vimrc disables defaults.vim and they get the famous barebones experience that we wanted to hide from them in the first place.

The second one was not directly affected, which is a good thing.

The third one was deeply affected because Bram basically forgot about their existence, just like you do.

A good scheme would have targeted only one category but there is a big obstacle: it is impossible to differentiate a "new user" from an "existing user without a vimrc" at startup. The presence of a vimrc is simply not a good enough heuristic and the proposed command-line flag and environment variable are not really improvements. Those are just more and more hard to find hacks. Besides, there are three categories of users so a boolean is simply not the answer. Also, at which point shall we decide when a "new user" starts to become an "existing user without a vimrc"?

My proposal:

Move the few settings that make sense from defaults.vim to the core as default values for built-in options. They are:
```
set ruler
set showcmd
set ttimeout
set ttimeoutlen=100
set display=truncate
set incsearch
set nrformats-=octal
```
I'm not sure about nolangremap but I guess it is OK to include it here.
Abandon those that make no sense and move the rest out of the way, to vimrc_example.vim.
Get rid of that impractical "new user" versus "existing user" framing forever.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Christian Brabandt

unread,

Jul 11, 2025, 10:18:14 AM7/11/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

the "existing user without carefully crafted settings".

I am wondering what shall that be a user without carefully crafted settings? A user that takes whatever is the default? Then that is the same as a new user, no? Or someone that just does not want defaults.vim. At which point he can export VIM_NO_LOAD_DEFAULTS and be fine, no?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Romain Lafourcade

unread,

Jul 11, 2025, 10:35:04 AM7/11/25

to vim/vim, vim-dev ML, Comment

romainl left a comment (vim/vim#14883)

Basically every user who knows how to use vi/Vim well enough to not have to cary their config as they hop from one machine to another. That's lots and lots of sysadmins for starters.

Lots of users value the stability and predictability associated with Vim's relatively slow pace of development. Those who don't already switched.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jul 11, 2025, 11:08:09 AM7/11/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

And those export VIM_NO_LOAD_DEFAULTS and are back in the pre Vim 7.4.2111 (before defaults.vim was introduced). So should be happy, no?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

D. Ben Knoble

unread,

Jul 11, 2025, 12:43:49 PM7/11/25

to vim/vim, vim-dev ML, Comment

benknoble left a comment (vim/vim#14883)

I guess it is fine if we are 100% against breaking change. (Which I would go for: never automatically load defaults.vim, add info to :intro that users can add runtime defaults.vim to get some "new defaults" if they want to.)

Unfortunately changes to :intro aren't visible enough because it hides when starting up with files to load (as you know).

Assuming we do take the direction in this series, providing signposts in the user manual for folks creating their first vimrc will be helpful.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jul 11, 2025, 1:44:32 PM7/11/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

Okay, I'll think about changing those defaults. Last time we changed some defaults, I got quite some push-back.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Damien Lejay

unread,

Jul 11, 2025, 2:09:29 PM7/11/25

to vim/vim, vim-dev ML, Comment

dlejay left a comment (vim/vim#14883)

Unfortunately changes to :intro aren't visible enough because it hides when starting up with files to load (as you know).

If the goal is to ensure users notice new defaults, then that should be addressed directly. MacVim, for example, shows a clear message to inform users about changes.

If Vim should have a frozen set of behaviours that people must rely on, then the option should be called accordingly and let have people call “vim --classic-mode” and/or “vim --vi-mode”.

In parallel, vim (with no flags) should aim to provide the best out-of-the-box experience for everyone, including beginners. One reasonable goal is to minimize how much customization is needed.

Lastly, I believe the Vim Project would benefit from articulating a Vision – a clear direction for what kind of user experience it wants to offer. Currently, the documentation describes what Vim is, but not what it wants to become. That would make it easier to not follow the path of least complaints, but rather the path of least resistance toward a coherent vision.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

James McCoy

unread,

Jul 12, 2025, 3:36:05 PM7/12/25

to vim/vim, vim-dev ML, Comment

jamessan left a comment (vim/vim#14883)

Okay, I'll think about changing those defaults. Last time we changed some defaults, I got quite some push-back.

This is the part that I find frustrating, especially since many of the complaints come from quite seasoned users who can easily adjust the setting to what they like.

As long as the changes in default behavior can trivially be reverted, then we shouldn't be afraid to change defaults.

That was the main thing defaults.vim got wrong, IMO. Since it had such complicated rules about when it was used, it made it hard to reason about how to change a particular setting that one didn't like while keeping the rest, which was a stark departure from the previous history of Vim. Even more so, since it completely ignored the system-wide vimrc in its logic, which ended up being a common place for sysadmins to put their desired settings.

I don't see the current proposal as improving on this situation.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Christian Brabandt

unread,

Jul 13, 2025, 3:14:55 AM7/13/25

to vim/vim, vim-dev ML, Comment

Closed #14883.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jul 13, 2025, 3:14:58 AM7/13/25

to vim/vim, vim-dev ML, Comment

chrisbra left a comment (vim/vim#14883)

Alright, I am dropping this. It doesn't seem be helpful.

I will try to gradually update the mentioned defaults, but there are still a few options in defaults.vim that are quite a bit controversial, like scrolloff and mouse. I won't touch those, they are too disruptive.

This is the part that I find frustrating, especially since many of the complaints come from quite seasoned users who can easily adjust the setting to what they like.

Yeah, you don't need to tell me. Quite frankly it's been an exhausting experience to try to improve this situation 🙈

On the other hand, I understand the complaints from seasoned users. It's annoying even if you know how to fix this and this surprise then may affect millions of users.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Reply all

Reply to author

Forward