[vim/vim] Provides a way to finally set the option, avoid overwritten it by other plugin (Issue #11255)

someoneonsmile

unread,

Oct 1, 2022, 6:20:18 AM10/1/22

to vim/vim, Subscribed

Provides a way to finally set the option, avoid overwritten it by other plugin

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
It is difficult to make config effect when some option overwritten by other plugin or some autocmd

Describe the solution you'd like
final set shiftwidth=4 or set$ shiftwidth=4

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

Shougo

unread,

Oct 1, 2022, 6:24:02 AM10/1/22

to vim/vim, Subscribed

Well, I know why the feature is needed.
Users don't want to be overwritten options values by plugins.
But it breaks existing plugins.

If plugins want to change the value?
Errors? or it is ignored?

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

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

someoneonsmile

unread,

Oct 1, 2022, 6:30:26 AM10/1/22

to vim/vim, Subscribed

warning once? probably this shouldn't be provided

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

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

someoneonsmile

unread,

Oct 1, 2022, 6:54:49 AM10/1/22

to vim/vim, Subscribed

another option to control its behavior？set opt_final_overwite='error|ignore'
it may not make sense

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

Bram Moolenaar

unread,

Oct 1, 2022, 8:01:56 AM10/1/22

to vim/vim, Subscribed

> Provides a way to finally set the option, avoid overwritten it by other plugin
>

> **Is your feature request about something that is currently impossible
> or hard to do? Please describe the problem.**

> It is difficult to make config effect when some option overwritten by
> other plugin or some autocmd
>

> **Describe the solution you'd like**

> final set shiftwidth=4 or set$ shiftwidth=4

You do not mention the context. Is this a plugin you install once? A
filetype plugin?

For a filetype plugin you can provide your own in "after" to override
what a standard filetype plugin has done.

Many plugins provide ways to configure them to your preferences.
Something like 'shiftwidth' is an obvious one.

Unless there is a very clear advantage, I don't think we should make
this more complicated.

--
You are Dead. Do you wish to restart, load, or quit?

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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

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

someoneonsmile

unread,

Oct 1, 2022, 8:22:18 AM10/1/22

to vim/vim, Subscribed

sorry, in my case is some options value in my after/ftplugin user config, overwritten by plugin's autocmd

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

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

someoneonsmile

unread,

Oct 1, 2022, 8:26:04 AM10/1/22

to vim/vim, Subscribed

It can be done without this feature, but it's easier with this

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

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

someoneonsmile

unread,

Oct 1, 2022, 8:33:45 AM10/1/22

to vim/vim, Subscribed

another case is i want to change the value of formatoptions but it was set in many default ftplugin files

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

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

Maxim Kim

unread,

Oct 1, 2022, 8:36:54 AM10/1/22

to vim/vim, Subscribed

another case is i want to change the value of formatoptions but it was set in many default ftplugin files

I use this autocmd to override what other ftplugins do:

    au Filetype * setl formatoptions-=cro

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

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

someoneonsmile

unread,

Oct 1, 2022, 8:40:17 AM10/1/22

to vim/vim, Subscribed

Thanks, that's what I did too, but I think it's more direct

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

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

someoneonsmile

unread,

Oct 1, 2022, 8:41:09 AM10/1/22

to vim/vim, Subscribed

I will turn it off if not necessary

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

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

Maxim Kim

unread,

Oct 1, 2022, 8:42:55 AM10/1/22

to vim/vim, Subscribed

I think this is more about ftplugin authors to not set options more than necessary.

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

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

someoneonsmile

unread,

Oct 1, 2022, 8:49:31 AM10/1/22

to vim/vim, Subscribed

Closed #11255 as completed.

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

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

Dave McCooey

unread,

Oct 1, 2022, 2:08:23 PM10/1/22

to vim...@googlegroups.com, reply+ACY5DGGUOTL2W7MOXJ...@reply.github.com, vim/vim, Subscribed

Many vim users, myself included, learn about filetype plugins

and autocommands only in an effort to disable a filetype plugin's

behavior of overriding settings specified in _vimrc.

For example, my _vimrc contains the following autocmd:

autocmd FileType * setlocal iskeyword=@,48-57,_,192-255

Moreover, this autocmd must be the last thing done in _vimrc,

because, as I understand it, filetype plugins are themselves run

from autocommands, which means any autocmd defined after

this one could potentially override its intended effect.

It took time and some research to figure out all of this trickery.

The proposal in Issue #11255, or something similar, would have

provided a far simpler solution.

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/vim/vim/issue/11255/issue_event/7500368098%40github.com.

vim-dev ML

unread,

Oct 1, 2022, 2:08:42 PM10/1/22

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

Many vim users, myself included, learn about filetype plugins
and autocommands only in an effort to disable a filetype plugin's
behavior of overriding settings specified in _vimrc.

For example, my _vimrc contains the following autocmd:

autocmd FileType * setlocal iskeyword=@,48-57,_,192-255

Moreover, this autocmd must be the *last thing* done in _vimrc,

because, as I understand it, filetype plugins are themselves run
from autocommands, which means any autocmd defined after
this one could potentially override its intended effect.

It took time and some research to figure out all of this trickery.

The proposal in Issue #11255, or something similar, would have
provided a far simpler solution.

On Sat, Oct 1, 2022 at 7:49 AM someoneonsmile ***@***.***>
wrote:

> Closed #11255 <https://github.com/vim/vim/issues/11255> as completed.

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

> <https://github.com/vim/vim/issues/11255#event-7500368098>.
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>

>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ***@***.***

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vim_dev/vim/vim/issue/11255/issue_event/7500368098%40github.com

> <https://groups.google.com/d/msgid/vim_dev/vim/vim/issue/11255/issue_event/7500368098%40github.com?utm_medium=email&utm_source=footer>
> .
>

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

lacygoill

unread,

Oct 1, 2022, 3:12:47 PM10/1/22

to vim/vim, vim-dev ML, Comment

Moreover, this autocmd must be the last thing done in _vimrc,

It doesn't need to be the last thing, but it needs to be installed after enabling the filetype plugins:

filetype plugin indent on

Which is why the latter command should be near the top of the vimrc.

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

You are receiving this because you commented.

Yee Cheng Chin

unread,

Oct 2, 2022, 8:56:19 AM10/2/22

to vim/vim, vim-dev ML, Comment

The proposal in Issue #11255, or something similar, would have provided a far simpler solution.

Seems to me the solution should be to write better plugins and have Vim default ones have sensible ways to configure whether these options get set or not. A new feature to completely lock a setting is going to introduce a lot of knock-on effects in my opinion and it doesn't seem clear from the proposal what a failure to set an option leads to. It would at least require a new builtin function for plugin to query whether an option is settable or not so the plugin could branch off to do something else instead. There are also some options where a plugin absolutely has to set or it just won't work at all, and now all plugin authors have to think about the dozens of options they set and go through each of them to check whether they are settable or not.

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

You are receiving this because you commented.

someoneonsmile

unread,

Oct 2, 2022, 11:35:03 AM10/2/22

to vim/vim, vim-dev ML, Comment

My initial thought was as an escape mechanism when user-set options didn't take effect and it was difficult to track where they were overridden. Give control to the user

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

You are receiving this because you commented.

someoneonsmile

unread,

Oct 3, 2022, 12:26:56 AM10/3/22

to vim/vim, vim-dev ML, Comment

I think the feature is a way(choose) conflict is handled rather than caused by, the conflict was handled by overwriting silent before and this is freezing.

When a plugin option conflicts with a user option, failing because the option is frozen by user is the same for the plugin as failing because the option is overwritten by user. I agree that no conflict is better.

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

You are receiving this because you commented.

someoneonsmile

unread,

Oct 3, 2022, 12:47:53 AM10/3/22

to vim/vim, vim-dev ML, Comment

What I understand is that a plugin should be a good helper, but the control is yours

For example, renovation workers can renovate any room, but you can lock the rooms you don't want to renovate.

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

You are receiving this because you commented.

Christian Brabandt

unread,

Oct 5, 2022, 8:35:51 AM10/5/22

to vim/vim, vim-dev ML, Comment

I believe you can also use an OptionSet autocommand, to enforce your personal options settings

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

You are receiving this because you commented.

chdiza

unread,

Oct 7, 2022, 9:49:16 AM10/7/22

to vim/vim, vim-dev ML, Comment

One can also do what I do, and disable the loading of ftplugins generally. I hate them with the fire of a thousand suns. For a few filetypes that I use frequently, I make my own custom settings, usually just to set &cms or &com or make a buffer-local command. It's much easier to disable ftplugins generally than to have to clutter my ~/.vim with an after dir tree.

As far as I can tell, disabling ftplugins just involves not having ":filetype on" in ~/.vimrc.