[vim/vim] do not automatically set user preferences like ts,sw,et (Issue #20036)
bugsbugsbux
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
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
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
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
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
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
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
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
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
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
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.
You are receiving this because you are subscribed to this thread.
Alla Santoshpavan
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.javafile, Vim might set tabs to 4 spaces; if you open a.jsfile, it might switch to 2 spaces. This follows the "Style Guide" of the language. - Project-Specific Rules (
.editorconfig): If your project has an.editorconfigfile, 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.vimordetectindent: 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.
You are receiving this because you are subscribed to this thread.
Tim Pope
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.
You are receiving this because you are subscribed to this thread.