[vim/vim] do not automatically set user preferences like ts,sw,et (Issue #20036)

bugsbugsbux

unread,

Apr 22, 2026, 5:11:02 AMApr 22

to vim/vim, Subscribed

bugsbugsbux created an issue (vim/vim#20036)

Please do not automatically set user preferences like tab settings
unless there is a really good reason to do so!

Problem:
constantly my config settings are overwritten by runtime/{ftplugin,indent}files for no good reason.
Undoing this is bothersome, because if

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

Christian Brabandt

unread,

Apr 22, 2026, 5:37:07 AMApr 22

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20036)

There is a solution for you: disable filetype and indent plugins completely.

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

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

bugsbugsbux

unread,

Apr 22, 2026, 5:55:20 AMApr 22

to vim/vim, Subscribed

bugsbugsbux left a comment (vim/vim#20036)

well, there are other settings in ftplugin too, which would then be disabled.

just enforce your own guidelines to not set user preferences, or at least wrap the settings like most ft plugins do.

then disable them by default and send a message to the user when entering filetype "ft specific settings available. activate with: let g.FT_recommended_style=1"

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

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

Char

unread,

Apr 22, 2026, 7:17:24 AMApr 22

to vim/vim, Subscribed

char101 left a comment (vim/vim#20036)

That's just how vim works.

For user specific setting, you override the runtime values in $VIMFILES/after/{syntax,indent,ftplugin}/{filetype}.vim. You don't put it in vimrc or $VIMFILES/{syntax,indent,ftplugin}/{filetype}.vim.

vimrc is for global values and $VIMFILES/{syntax,indent,ftplugin}/{filetype}.vim is for filetype without builtin support.

https://vimhelp.org/options.txt.html#after-directory

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

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

Christian Brabandt

unread,

Apr 22, 2026, 7:40:13 AMApr 22

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20036)

This is highly controversial and what one sees at a user preference, other do not and sometimes the language does require certain settings (et vs. Makefiles, python recommended style, etc). There is not a general solution that fits every users requirements. You can also override specific filetype plugins, see :h ftplugin-overrule and not set any un-wanted options for the filetype which bother you the most.

If you want to globally change it (meaning in our project here and all downstream versions), you'll have to discuss with the maintainers/owners for each affected filetype plugin (or if they are un-maintained, feel free to open an issue or PR here). But expect a bit discussion and slowly moving forward and it may also be slightly backwards incompatible.

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

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

bugsbugsbux

unread,

Apr 22, 2026, 7:53:18 AMApr 22

to vim/vim, Subscribed

bugsbugsbux left a comment (vim/vim#20036)

I updated the issue to be more explicit why i believe this is a bug not just opinion and why the current process is problematic

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

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

Christian Brabandt

unread,

Apr 22, 2026, 8:06:54 AMApr 22

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20036)

Typically, options should be documented in either :h ft-<filetype>-plugin for filetype plugins or :h ft-<filetype>-syntax (for syntax options) or :h ft-<filetype>-indent (for indent options).

Now some options make more sense for indenting, so those options are typical in a indent plugin rather then the filetype plugin.

For Markdown specifially, please discuss with @tpope here: https://github.com/tpope/vim-markdown

For typst, I still do not see what is wrong with separating those options over the relevant fileype/plugin/indent runtime files. What option exactly do you feel wrong for typst? Those seem to make sense from a brief look for a filetype plugin.

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

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

bugsbugsbux

unread,

Apr 22, 2026, 11:38:02 AMApr 22

to vim/vim, Subscribed

bugsbugsbux left a comment (vim/vim#20036)

I still do not see what is wrong with separating those options

I am not saying it's wrong in general; i am saying, it's wrong to not be consistent.
Either everything in one file, or always split it up.
The way it is, i have to be a vim expert just to understand what is going on,
because i cannot infer from what i am seeing (that is, markdown sets indent stuff
in the obvious place: ftplugin) where to look for more filetype specific settings;
if i look at runtime/ftplugin/typst.vim i will never guess that there is also runtime/indent/typst.vim
It's also a problem the other way around: if i know indent stuff is in runtime/indent
then i just look for runtime/indent/markdown.vim and do not find it, coming to the
conclusion: markdown does not have indent settings (which it does).

I also cannot rely on :help because :h ft-typst-indent does not exist
and :h ft-typst-plugin does not mention it.
Why is that? Probably because its so fragmented neither the author of these ft specific settings
nor the maintainer remembered how this all fits together
and that there also needs to be a wiki page.
Will this wiki page be updated if the settings are changed? I have a guess.

How about not autoloading runtime/{indent,...} but only runtime/ftplugin/;
source the other files from there explicitly and
inject the documentation from there in some way,
to keep it close together, so everyone easily recognizes the relationship.

Typically, options should be documented in either :h ft--plugin for filetype plugins or :h ft--syntax (for syntax options) or :h ft--indent (for indent options).

Actually, why even have separate documentation?
This just creates the danger of being forgotten or getting out of sync.
Can't you just open the ftplugin/FT.vim and fold it to only show the comments?
In this case it would be even more beneficial to just have a single ftplugin/FT.vim or
explicit sourcing from there.

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

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

chdiza

unread,

Apr 26, 2026, 2:59:31 PMApr 26

to vim/vim, Subscribed

chdiza left a comment (vim/vim#20036)

@bugsbugsbux I also absolutely cannot stand ftplugins and the unexpected, inconsistent, intrusive modifications they perform. They made it harder for me to learn Vim. Fortunately ftplugins are "off" by default, and for over twenty years now: I just don't enable them. For those few filetypes for which I want special settings, I either have my own "fake" ftplugins in my ~/.vim that are invoked by FileType autocommands---or if the customization is tiny, it's just a FileType autocommand in the vimrc to do something like setting &com.

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.

Enno

unread,

Apr 27, 2026, 5:46:26 AMApr 27

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#20036)

if i look at runtime/ftplugin/typst.vim i will never guess that there is also runtime/indent/typst.vim
It's also a problem the other way around: if i know indent stuff is in runtime/indent
then i just look for runtime/indent/markdown.vim and do not find it, coming to the
conclusion: markdown does not have indent settings (which it does).

...

I also cannot rely on :help because :h ft-typst-indent does not exist
and :h ft-typst-plugin does not mention it.
Why is that? Probably because its so fragmented neither the author of these ft specific settings
nor the maintainer remembered how this all fits together
and that there also needs to be a wiki page.
Will this wiki page be updated if the settings are changed? I have a guess.

Keeping code in sync with docs got in principle easy. In practice impossible as it requires conset of every maintainer of which many will not reply indefinitely, as in #16083

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

Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.

Justin M. Keyes

unread,

Apr 27, 2026, 6:08:29 AMApr 27

to vim/vim, Subscribed

justinmk left a comment (vim/vim#20036)

it requires conset of every maintainer

I think an exception was made for 'commentstring'? #14843 We didn't wait for 65 maintainers there.

ftplugins must follow some guidance, they can't just do anything. So changing the guidance when needed is perfectly feasible.

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Alla Santoshpavan

unread,

Apr 27, 2026, 8:33:40 AMApr 27

to vim/vim, Subscribed

SantoshPavan143 left a comment (vim/vim#20036)

This is a classic Vim philosophy debate. The general rule in the Vim community is that your .vimrc should be a personal sanctuary, and plugins or system-wide configurations should almost never override your global tab settings ($tabstop$, $shiftwidth$, $expandtab$) without your explicit permission.

However, since Vim is a highly contextual editor, there are a few "really good reasons" why these might be changing automatically.

1. The "Good Reasons" for Auto-Settings

If you notice your tabs changing unexpectedly, it is usually because one of these features is trying to be helpful:

Filetype Detection (filetype plugin indent on): This is the most common reason. If you open a .java file, Vim might set tabs to 4 spaces; if you open a .js file, it might switch to 2 spaces. This follows the "Style Guide" of the language.
Project-Specific Rules (.editorconfig): If your project has an .editorconfig file, many Vim plugins will automatically apply those settings to ensure you don't break the codebase's formatting.
Vim Modelines: If a file contains a line like /* vim: set ts=4 sw=4 tw=0 noet : */ at the very top or bottom, Vim will prioritize that over your global settings for that specific file.
sleuth.vim or detectindent: These popular plugins "sniff" the file you just opened. If the file already uses 8-space tabs, the plugin will set your buffer to 8-space tabs so you don't create a "messy" file with mixed indentation.

2. How to Stop the Overriding

If you want to maintain a strict, consistent preference regardless of what a plugin thinks, use these strategies:

A. The "Last Word" Strategy

Place your settings at the very end of your ~/.vimrc. However, filetype plugins often run after the vimrc. To truly force your way, use an Autocommand:

" Force 4-space tabs for EVERY file, overriding filetype plugins
autocmd FileType * setlocal tabstop=4 shiftwidth=4 expandtab

B. Disable Filetype Indentation

If you hate that Vim tries to guess the "correct" indentation for different languages, you can turn off the indent-specific part of filetype detection:

filetype plugin on
" filetype indent off  <-- This prevents lang-specific indent files from loading

3. Debugging: "Who changed my settings?"

If your tabs are still changing and you don't know why, you can "interrogate" Vim while the file is open. Type this in Command Mode:

:verbose set tabstop?

Vim will respond with: tabstop=2
Last set from ~/.vim/bundle/vim-javascript/ftplugin/javascript.vim

This tells you exactly which file or plugin is the "culprit."

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Tim Pope

unread,

Apr 30, 2026, 12:03:41 PMApr 30

to vim/vim, Subscribed

tpope left a comment (vim/vim#20036)

Left my thoughts about this from the perspective of Markdown at tpope/vim-markdown#229.

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Magnus Groß

unread,

May 20, 2026, 3:44:35 PMMay 20

to vim/vim, Subscribed

vimpostor left a comment (vim/vim#20036)

I think it would already be much of an improvement if there was a generic opt-out g:ft_recommended_style that one could set to disable all recommended styles. Right now we have to disable it for every filetype:

let g:markdown_recommended_style = 0
let g:python_recommended_style = 0
let g:rust_recommended_style = 0
...

" instead add a generic opt-out
let g:_ft_recommended_style = 0

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Christian Brabandt

unread,

May 25, 2026, 12:56:41 PMMay 25

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20036)

Okay, how about we make this official then:

diff --git a/runtime/doc/usr_51.txt b/runtime/doc/usr_51.txt
index 15ca4f500..c874e0f2a 100644
--- a/runtime/doc/usr_51.txt
+++ b/runtime/doc/usr_51.txt
@@ -573,6 +573,39 @@ be set accordingly.

 Both these variables use legacy script syntax, not |Vim9| syntax.

+RECOMMENDED STYLE                              *ft_recommended_style*
+
+A filetype plugin or indent script may set options that reflect a
+recommended or commonly used style for that filetype, rather than a strict
+requirement of the language.  Since not every user wants these stylistic
+settings, guard them so they can be disabled.
+
+Check two variables, the filetype-specific one first, then the general one,
+defaulting to enabled (1): >
+
+       if get(g:, '<filetype>_recommended_style',
+               \ get(g:, 'filetype_recommended_style', 1))
+         " set the recommended style options here
+       endif
+
+Replace <filetype> with the actual filetype name, e.g. "python" gives
+g:python_recommended_style.
+
+This lets the user turn recommended style settings off for all filetypes: >
+
+       let g:filetype_recommended_style = 0
+
+or for one filetype while leaving the rest enabled: >
+
+       let g:python_recommended_style = 0
+
+The filetype-specific variable takes precedence over the general one, so a
+user can disable styling everywhere with g:filetype_recommended_style and
+re-enable it for a single filetype by setting g:<filetype>_recommended_style
+to 1 (or vice versa).
+
+Settings that are required for the language to work correctly (not merely
+stylistic) should not be placed behind this guard.

 FILE NAME

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Christian Brabandt

unread,

May 26, 2026, 2:37:00 PMMay 26

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20036)

okay, I'll merge it, hope this helps.

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Magnus Groß

unread,

May 26, 2026, 3:10:10 PMMay 26

to vim/vim, Subscribed

vimpostor left a comment (vim/vim#20036)

okay, I'll merge it, hope this helps.

Thanks, but I just saw the help tag is named inconsistently

ft_recommended_style
g:filetype_recommended_style

The section should probably also have the label prefix filetype, unless this was intentional.

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Christian Brabandt

unread,

May 26, 2026, 3:17:13 PMMay 26

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20036)

you mean: *filetype_recommended_style*?

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

Magnus Groß

unread,

May 26, 2026, 3:39:49 PMMay 26

to vim/vim, Subscribed

vimpostor left a comment (vim/vim#20036)

you mean: *filetype_recommended_style*?

Yes, for consistency.

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

Triage notifications on the go with GitHub Mobile for iOS or Android.

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

dkearns

unread,

7:52 AM (5 hours ago) 7:52 AM

to vim/vim, Subscribed

dkearns left a comment (vim/vim#20036)

There is also no_plugin_maps...

Disabling filetype plugin maps (loosely defined) with no_plugin_maps = 1 and no_{filetype}_maps but doing the same for style options with filetype_recommended_style = 0 and {filetype}_recommended_style is a grating user experience.

This global variable configuration 'system' was inadequate twenty years ago and naming consistency is impossible to manage at this point. I can't recall the last time I set a config variable without checking the help or implementation.

What about the filetype_{extension} overrule variables. What happens to a new "ft" filetype? Is no_plugin_maps a "no" filetype config variable? Why "plugin" vs "filetype"? Are the general indent plugin config variables supposed to be "indent" prefixed when we already have an "indent" filetype?

ftplugin_recommended_style should also be in the running, in the interests of fairness.

:let g: reveals that there is almost no rhyme or reason to the naming. We need a proper plugin configuration system, probably as an extension to options, but even g:__CONFIG = #{ vim: ..., user: ... } would be better at this point.

See #17119 for some other discussion.

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

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

Justin M. Keyes

unread,

8:14 AM (4 hours ago) 8:14 AM

to vim/vim, Subscribed

justinmk left a comment (vim/vim#20036)

This global variable configuration 'system' was inadequate twenty years ago and naming consistency is impossible to manage at this point

and yet, we can at least prevent even more inconsistency by simply fixing the recent naming mistake. oh well.

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

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

dkearns

unread,

11:43 AM (1 hour ago) 11:43 AM

to vim/vim, Subscribed

dkearns left a comment (vim/vim#20036)

Well, it's not clear to me that it is a mistake.

There's arguably a precedent for g:filetype_ in the overrule variables. There's also the unabbreviated g:syntax_ and we do have g:indent_ in use.

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

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

Justin M. Keyes

unread,

11:51 AM (1 hour ago) 11:51 AM

to vim/vim, Subscribed

justinmk left a comment (vim/vim#20036)

There's also the unabbreviated g:syntax_ and we do have g:indent_ in use.

Those are are unrelated to ftplugins, which is the convention in question, and for which only ft_xx is the documented, existing convention.

idc, nobody here gives a shit about consistency.

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

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

Reply all

Reply to author

Forward