Update defaults.vim about vim

[jamessan]

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.

[chrisbra]

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)

[jamessan]

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.

[habamax]

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.

[AndrewRadev]

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 say they 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 persisting settings to a config file feels like an earlier thing to teach to me.

In the class, I ended up going through all the settings and autocommands in "defaults.vim" and explaining them and moving them manually, giving them an unofficial homework to do the same, but it was a fairly dry process which I would have rather done later when they knew what an autocommand is (which the defaults file includes).

Removing i from complete: As an avid user of and I don't like how they hang on c projects to scan all my include files.

I do support this: it seems logical to follow includes, but I definitely remember feeling slowdowns, though it was a long time ago and I don't even remember which language it was. Might have been PHP where some require was including a massive auto-generated file. It can be risky.

[vim-ml]

* 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

[benknoble]

• 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.

[saccarosium]

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

[chrisbra]

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 🙈

[saccarosium]

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.

[nickspoons]

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.

[saccarosium]

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.

[lkintact]

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 habit though.

[nickspoons]

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.

[chrisbra]

Okay, that leaves only the complete option.

[matveyt]

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).

[matveyt]

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.

[matveyt]

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

[saccarosium]

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