[vim/vim] Update defaults.vim (Issue #14853)

Luca Saccarola

unread,

May 26, 2024, 7:22:20 AMMay 26

to vim/vim, Subscribed

I think is time to update defaults.vim to include some nice to have settings and mapping. After spending some times using neovim and toying around with vim-fugitive. I do really appreciate the better defaults and the less line on my vimrc.

The most important settings to update are:

Mapping Y by default to y$: This is simply better in every way because it behaves like the other capital letter commands.
Enabling hidden: At this point I'm 100% sure that everyone wants to edit two separate file without saving first.
Enabling autoindent: I think this make life easier when coding and usually is expected.
Enabling autoread: I also think this is a no brainer since I'm almost certaint that you want to update your buffers if you modify the file externaly.
Enabling modeline: This is used by a lot of file, including the entire vim source code, so having this by default is only helpful even to the user that doesn't know anything about it.

Some quality of life improvements, but optional, settings are:

Removing i from complete: As an avid user of <C-n> and <C-p> I don't like how they hang on c projects to scan all my include files.
Add pum to wildoptions: I find it a lot more readable than the default.
Enabling smarttab: Really good while editing.

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

Christian Brabandt

unread,

May 26, 2024, 12:41:03 PMMay 26

to vim/vim, Subscribed

Well, out of those:

mapping Y this is definitly a user preference, I don't think this belongs to defaults.vim
hidden, I like it, but you may end up accumulating buffers, when you actually wanted to have them properly closed. A crash or :qa! could have unwanted consequences and :set nohidden forces you think if you want to write the current buffer and start editing a new one. I think this is definitly an option that a user should set intentionally, not have it set un-intentionally
autoindent I don't think this makes sense because defaults.vim already loads filetype specific indent scripts, which is usually the better indent alternative
modline is already the default for Vim, we don't need to touch this one
smarttab I don't have it and I can imagine it may be surprising if a <bs> starts deleting more than one space suddenly.

Out of those suggested, the following may make sense

autoread I don't have it and I don't remember have needed it ever, not sure on this one
complete not sure, it may make sense
pum may make sense, but don't know if this will work on Vim tiny (haven't tested it)

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

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

Luca Saccarola

unread,

May 26, 2024, 4:31:41 PMMay 26

to vim/vim, Subscribed

hidden, I like it, but you may end up accumulating buffers, when you actually wanted to have them properly closed. A crash or :qa! could have unwanted consequences and :set nohidden forces you think if you want to write the current buffer and start editing a new one. I think this is definitly an option that a user should set intentionally, not have it set un-intentionally

I get the point. But objectively I really didn't see any vimrc without set hidden in it. It so common that at this point I really think it is not so opinionated that is so crazy to have it as a default.

autoread I don't have it and I don't remember have needed it ever, not sure on this one

I really can't tell you the times I accidentally undo changes to a file because of this. Sometimes I open my code both in vim and in a Intellij editor to use the visual debugger. Since I hadn't autoread enabled when I made a change to the file with the IDE and than open vim - with the older file content saved to the buffer - and save the file I did overwritten the changes I just did in the IDE. Now I know a lot more about vim and its design. But putting myself in the shoes of a newbie I would be so confused that this program doesn't reflect the changes I make from outside.

pum may make sense, but don't know if this will work on Vim tiny (haven't tested it)

From my testing I don't think vim-tiny actually has wildmenu. But I don't really think this should be a blocker.

complete not sure, it may make sense

i option confuse me a little since I think it is much better to use tags or omnifunc to complete from a header since they do a much better job and - usually - they are "expected" to be slow. On the other hand <C-{p|n}> I see them more as a quick completion of a word and the fact that usually hangs everything is not a good experience.

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

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

Nick Jensen

unread,

May 26, 2024, 5:06:31 PMMay 26

to vim/vim, Subscribed

I get the point. But objectively I really didn't see any vimrc without set hidden in it. It so common that at this point I really think it is not so opinionated that is so crazy to have it as a default.

Seeing :set hidden in .vimrcs is not a good test - by the time people are saving and sharing their .vimrcs they have a good idea of what different options do. I have encountered many people in #vim on IRC that do not enable 'hidden', either because the don't know about it, or intentionally because they don't like to lose track of unmodified buffers. I don't think it should be enabled by default (even though I personally would not want to work without it).

autoread I don't have it and I don't remember have needed it ever, not sure on this one

I really can't tell you the times I accidentally undo changes to a file because of this. Sometimes I open my code both in vim and in a Intellij editor to use the visual debugger. Since I hadn't autoread enabled when I made a change to the file with the IDE and than open vim - with the older file content saved to the buffer - and save the file I did overwritten the changes I just did in the IDE.

When you try to save a file in vim, when the file has been externally modified, vim warns you:

WARNING: The file has been changed since reading it!!!
Do you really want to write to it (y/n)?

I do use 'autoread' and think it is a good option. But it's not essential in the way described, and don't know whether it makes sense to have as a default. What if the vim version is the correct version? Will a non-expert know how to retrieve the version they previously had? It might not be obvious to them that they can do that with u.

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

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

Luca Saccarola

unread,

May 26, 2024, 5:30:42 PMMay 26

to vim/vim, Subscribed

What if the vim version is the correct version? Will a non-expert know how to retrieve the version they previously had? It might not be obvious to them that they can do that with u.

I don't really know how common it is.

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

lkintact

unread,

May 26, 2024, 5:53:10 PMMay 26

to vim/vim, Subscribed

Add pum to wildoptions: I find it a lot more readable than the default.

I just tried setting 'wildoptions' to pum and didn't like it: it blocks the view if there are many matches. Perhaps it's just a matter of habbit though.

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

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

Nick Jensen

unread,

May 26, 2024, 5:55:35 PMMay 26

to vim/vim, Subscribed

I just tried setting 'wildoptions' to pum and didn't like it: it blocks the view if there are many matches. Perhaps it's just a matter of habbit though.

I like it much better, I find it hard to read the options when they are spread out horizontally. But yes, a matter of habit.

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

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

Christian Brabandt

unread,

May 27, 2024, 2:08:30 AMMay 27

to vim/vim, Subscribed

Okay, that leaves only the complete option.

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

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

matveyt

unread,

May 27, 2024, 5:50:44 AMMay 27

to vim/vim, Subscribed

Scanning include files may be really slow, so disabling it feels like a right thing to do. While other suggestions are highly opinionated and should not be accepted, imo (though I admit I use few of them myself).

Talking of other options, I also believe that confirm and virtualedit=all could be set by default to better match existing user experience. Yet another candidate is undofile (imo, it's a shame that one of the best and most powerful Vim's features is still disabled by default).

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

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

Maxim Kim

unread,

May 27, 2024, 6:00:36 AMMay 27

to vim/vim, Subscribed

I don't think virtualedit=all is a good idea. Less intrusive block might be though.

Anyways, defaults.vim usually leads to all sorts of surprises when user wants to add brand new setting, creates .vimrc and gets nothing like it was before.

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

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

Andrew Radev

unread,

May 28, 2024, 7:15:54 AMMay 28

to vim/vim, Subscribed

I get the point. But objectively I really didn't see any vimrc without set hidden in it. It so common that at this point I really think it is not so opinionated that is so crazy to have it as a default.

I'm a Vim power user and I don't have set hidden in my config. If I move away from a file with unsaved changes, it was a mistake of some kind and I'll get an error on quit and get kind of annoyed. For a beginner, I'd imagine it would be really confusing to see that a file was unmodified, but it's hidden somewhere, if they don't know about buffer-switching yet. Everybody has their own workflow, I believe people in this thread that can't work without set hidden, but I couldn't work with it.

Anyways, defaults.vim usually leads to all sorts of surprises when user wants to add brand new setting, creates .vimrc and gets nothing like it was before.

To share my own experience of teaching Vim in an elective university course, I agree that it's a problem. What I'd like to show is something like:

You can :set relativenumber to get relative numbers (for example)
If you like it, you can keep it by doing :edit $MYVIMRC, then put that in the file, then just write and :source $MYVIMRC, and this always works and is portable regardless of what OS you're using

Except this is an issue, because if they do this, they'll change a number of settings unintentionally. I have to first teach them about defaults.vim, which is at least described clearly in the documentation in the "starting" section, but it does add a non-intuitive middle step. I don't have a good suggestion other than maybe creating a :CreateMYVIMRC command or something that bootstraps that file, maybe in an opt plugin that is sourced by default by defaults.vim? Which would not only create the file, but put the relevant lines on top:

unlet! skip_defaults_vim
let skip_boostrap_command = 1 " so the `opt` plugin is no longer loaded?
source $VIMRUNTIME/defaults.vim

Maybe that's overkill. The idea would be to simplify early user bootstrapping by having a list of commands to run without needing to understand file sourcing, or even window-jumping to copy the lines from the help and paste them. I realize navigating windows is a foundational skill, but writing settings to a file feels like an earlier thing to teach to me.

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

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

matveyt

unread,

May 28, 2024, 8:41:28 AMMay 28

to vim/vim, Subscribed

I don't have a good suggestion other than maybe creating a :CreateMYVIMRC command or something that bootstraps that file, maybe in an opt plugin that is sourced by default by defaults.vim? Which would not only create the file, but put the relevant lines on top

In fact, there is already such menu item in GVim (Edit/Startup Settings). Except, it does not add anything if no file exists, but it is trivial to implement. Not sure if we should do this, though.

The idea would be to simplify early user bootstrapping by having a list of commands to run without needing to understand file sourcing, or even window-jumping to copy the lines from the help and paste them. I realize navigating windows is a foundational skill, but persisting settings to a config file feels like an earlier thing to teach to me.

Imo, defaults.vim is overrated. It is okay to live without it completely. All one needs to do is to setup colors/font to his preference and is good to go. Later he can learn how to save his preferences, and so what is vimrc at all. And after that what are some extra features (from defaults.vim or elsewhere) one, maybe, would use.

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

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

D. Ben Knoble

unread,

May 28, 2024, 2:29:45 PMMay 28

to vim/vim, Subscribed

defaults.vim has already caused at least one major headache. Do we want to repeat that with opinionated changes?
Does invoking Vim as vi use defaults.vim? Would changes there affect POSIX-compatibility in any meaningful way?
I think autoindent might be the only really non-controversial option change, but it probably still has a debate. Do we really want to get bogged down in endless debates about what is part of the defaults.vim experience?

All this to say, this might be endless bikeshedding. There are probably new users who wish defaults.vim was a little better (though they may not have the vocabulary to say it that way if they don't know about defaults.vim). There are probably also users who run Vim with absolutely no ~/.vim/vimrc/configuration of any kind who would not appreciate such changes. How do you determine who "wins"?

It might be useful to articulate the "strategy" of Vim in order to provide a clear way to settle such problems. I think there has been an implicit direction to preserve backwards compatibility while making improvements, but recently I've seen different understandings of what that means lead to disagreement (healthy or otherwise).

To that end, I propose writing down statements of the form "Vim values X and therefore does Y." Such a collection could meaningfully be debated, and should be, but if accepted by the community (as a living document) it could be a very useful framework for conversations like this.

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

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

James McCoy

unread,

May 28, 2024, 3:23:53 PMMay 28

to vim/vim, Subscribed

It might be useful to articulate the "strategy" of Vim in order to provide a clear way to settle such problems.

From my perspective, Vim's strategy used to be to gracefully upgrade the user's experience as they became more familiar with Vim. A plain Vim install (with no config files) would behave relatively close to vi. Create a vimrc (even an empty one) and you would be upgraded to Vim defaults. All was good.

Then there was a desire to expose more users improvements that had happened in the intervening decade or so and defaults.vim was born. However, this regressed the previous behavior of gracefully improving behavior. Now, no config files presents the user with "old Vim defaults + new settings", which is good. However, as soon as the user creates a vimrc they lose the "+ new settings" because defaults.vim is no longer sourced. This is a regression in behavior from their perspective and they need to figure out how to restore any of that behavior they had gotten used to.

Making defaults.vim always apply, with documented ways to revert the settings (for things that aren't simply toggling options) would be an improvement in the consistency of Vim's behavior.

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

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

Luca Saccarola

unread,

May 28, 2024, 4:57:18 PMMay 28

to vim/vim, Subscribed

To that end, I propose writing down statements of the form "Vim values X and therefore does Y." Such a collection could meaningfully be debated, and should be, but if accepted by the community (as a living document) it could be a very useful framework for conversations like this.

It would be extremely helpful. I would be make it clearer what are the value of vim and what expect from the editor going forward

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

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

Christian Brabandt

unread,

May 29, 2024, 7:59:31 AMMay 29

to vim/vim, Subscribed

we are getting a bit side tracked here. Potentially because defaults nowadays mean something different for everybody :/

I didn't want to touch this topic of "fixing" the load-order of defaults.vim, but the last comments made me think...
So what if we make defaults.vim loads always (before $MYVIMRC)? This could still potentially upset anybody who intentionally did not enable some options from it and might be therefore upset by that behaviour. Perhaps with an opt-out behaviour of setting an environment variable (for the current behaviour)? But not sure if we would risk another outrage with such a change 🙈

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

vim-dev ML

unread,

May 29, 2024, 8:17:55 AMMay 29

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

* James McCoy ***@***.***> [240528 15:23]:

> > It might be useful to articulate the "strategy" of Vim in order to
> > provide a clear way to settle such problems.
>

> From my perspective, Vim's strategy _used_ to be to gracefully upgrade

> the user's experience as they became more familiar with Vim. A plain
> Vim install (with no config files) would behave relatively close to
> vi. Create a vimrc (even an empty one) and you would be upgraded to
> Vim defaults. All was good.
>
> Then there was a desire to expose more users improvements that had
> happened in the intervening decade or so and defaults.vim was born.

> However, this _regressed_ the previous behavior of gracefully

> improving behavior. Now, no config files presents the user with "old
> Vim defaults + new settings", which is good. However, as soon as the
> user creates a vimrc they lose the "+ new settings" because
> defaults.vim is no longer sourced. This is a regression in behavior
> from their perspective and they need to figure out how to restore any
> of that behavior they had gotten used to.
>

> Making defaults.vim _always_ apply, with documented ways to revert the

> settings (for things that aren't simply toggling options) would be an
> improvement in the consistency of Vim's behavior.

While I agree with your sentiment, I am more in line with D. Ben
Knoble's opinion that defaults.vim is really starting to become an
endless bikeshedding exercise.

I would be very annoyed at having defaults.vim all of a sudden be
sourced the next time I upgrade Vim (or the Debian vim package). I have
already copied the parts I want, and have intentionally left out the
parts I don't want. While I suspect there are plenty of experienced
users who already source defaults.vim in their personal vimrc, I think
most of those who don't would agree with my annoyance.

:help vimrc points to :help vimrc-intro, which recommends sourcing
defaults.vim. I think most new users who are creating a vimrc for the
first time will find their way to these help topics. I do think it
would be good to update vimtutor Lesson 7.2 to insert between points 1
and 2 something that points to both help topics. Mentioning
defaults.vim there might also be worthwhile.

I don't think making defaults.vim always apply is a good idea overall.

...Marvin

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

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

matveyt

unread,

May 29, 2024, 8:32:56 AMMay 29

to vim/vim, vim-dev ML, Comment

Please, no. This is what we've already seen in the Debian vim package. And it's horrible.

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

You are receiving this because you commented.

Ajit Thakkar

unread,

May 29, 2024, 8:44:16 AMMay 29

to vim_dev

Forcing defaults.vim to always load is not a good idea.

I have used Vim since version 3 . The only time I was really upset by an incompatible change was when version 7.4.xxxx introduced defaults.vim

Ajit

James McCoy

unread,

May 29, 2024, 5:32:02 PMMay 29

to vim/vim, vim-dev ML, Comment

I would be very annoyed at having defaults.vim all of a sudden be sourced the next time I upgrade Vim (or the Debian vim package). I have already copied the parts I want, and have intentionally left out the parts I don't want. While I suspect there are plenty of experienced users who already source defaults.vim in their personal vimrc, I think most of those who don't would agree with my annoyance.

This is exactly the problem, in my view, with the current implementation of defaults.vim. Rather than opting out of what you didn't like, you had to copy the parts that you did like into your own config. Now you have also implicitly opted out of any future changes that the Vim developers may think make sense as pseudo-defaults (via the defaults.vim mechanism).

It should be possible for Vim to decide that it wants to enable some functionality by default, but allow people that don't want that to opt out. This is how most software works. Vim has historically been very conservative when it comes to exposing new functionality by default, which is fine, but for some reason has settled on a suboptimal way to handle changing the default behavior.

This is what we've already seen in the Debian vim package.

No, this is what you see in Vim. I have done nothing in Debian to change Vim's behavior when it comes to defaults.vim, even though I have received many complaints about it. This is something that I've always said needs to be decided upstream.