[vim/vim] defaults: enable by default wildmenu even without defaults.vim (PR #16055)
Luca Saccarola
Hi,
I believe that wildmenu should be enabled even without defaults.vim. It is such a useful feature and the majority of user will want that. There isn't really a gain in disabling it by default and relegate it to defaults.vim.
Most novice users want this enabled in every situation and a lot of them don't know that if you create a .vimrc defaults.vim won't be loaded anymore. I've just have a chat with a friend yestarday about this (and it isn't the first time). The only people I can see bothering is people that, for some reason, don't like completion. I think this days they are a very small group.
I don't know if I need to check if wildmenu is enabled or if I'm doing this correctly feedback will really be appreciated :).
Do I need to wrap it in a #ifdef FEAT_WILDMENU or something like that?
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/16055
Commit Summary
- e152dae defaults: always enable wildmenu
File Changes
(3 files)
- M runtime/defaults.vim (1)
- M runtime/doc/options.txt (6)
- M src/optiondefs.h (2)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra commented on this pull request.
> @@ -5325,7 +5325,7 @@ A jump table for the options with a short description can be found at |Q_op|. The cursor is displayed at the start of the space a Tab character occupies, not at the end as usual in Normal mode. To get this cursor position while displaying Tabs with spaces, use: > - :set list lcs=tab:\ \ + :set list lcs=tab:\ \
that looks wrong and unrelated
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
thanks
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Nick Jensen
@nickspoons commented on this pull request.
> @@ -7385,7 +7385,7 @@ A jump table for the options with a short description can be found at |Q_op|. feature} String to put at the start of lines that have been wrapped. Useful values are "> " or "+++ ": > - :set showbreak=>\ + :set showbreak=>\
This one is also wrong and unrelated
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
This default behavior change will cause confusion to many existing users.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra commented on this pull request.
> @@ -7385,7 +7385,7 @@ A jump table for the options with a short description can be found at |Q_op|. feature} String to put at the start of lines that have been wrapped. Useful values are "> " or "+++ ": > - :set showbreak=>\ + :set showbreak=>\
same here, please do not strip those trailing whitespace
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
This default behavior change will cause confusion to many existing users.
Do you think so? I think it should be fine, we are just moving the default from defaults.vim to the C code
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Luca Saccarola
This default behavior change will cause confusion to many existing users.
I don't really think so wildmenu is really a popular option so I expect very minimal confusion. It will probably be annoying for the ones that for some reason don't like it but I think this is better for the majority of the users
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
This default behavior change will cause confusion to many existing users.
Do you think so? I think it should be fine, we are just moving the default from defaults.vim to the C code
A large number of embedded devices ship Linux with Vim. To reduce the runtime footprint, the
Vim runtime files (including defaults.vim) are not part of these images. In these cases, wildmenu
is not enabled by default. Now with this change, it will be enabled by default and will be a surprise
to a large number of users.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
This default behavior change will cause confusion to many existing users.
I don't really think so wildmenu is really a popular option so I expect very minimal confusion. It will probably be annoying for the ones that for some reason don't like it but I think this is better for the majority of the users
Maintaining backward compatibility is important and surprising the users with the change in behavior
when upgrading from one version to another is not good.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Hm, we are running into the old defaults.vim discussion again, however I am not convinced this change will really annoy people.
Let's take this as a test if people are complaining when moving default values from defaults.vim to the C code. I am ready to roll this back, if this is really an issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gabriel Dupras
Some keys have a different behaviour after completion depending if wildmenu is set or not.
For example, after pressing <Tab> for completion, <Left> moves the cursor one character to the left with nowildmenu but selects the previous match with wildmenu.
An other example. After completing a path with <Tab>, <Up> recalls a matching command from history with nowildmenu but moves up a directory with wildmenu.
This might throw off people used to the nowildmenu behavior.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Luca Saccarola
An other example. After completing a path with , recalls a matching command from history with nowildmenu but moves up a directory with wildmenu.
This is wrong is not affected.
For example, after pressing for completion, moves the cursor one character to the left with nowildmenu but selects the previous match with wildmenu.
This is very minor if they press they can get rid of the wildmenu and use
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Luca Saccarola
Maintaining backward compatibility is important and surprising the users with the change in behavior when upgrading from one version to another is not good.
You are correct but depends on the type of behavior change. As stated before this is a VERY popular option and very unlikely to be confusing.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gabriel Dupras
This is wrong is not affected.
See :h c_<Up>:
<Up> recall older command-line from history, whose beginning
matches the current command-line (see below). See 'wildmenu'
for behavior during wildmenu completion mode.
And :h 'wildmenu':
<Up> - in filename/menu name completion: move up into
parent directory or parent menu.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Luca Saccarola
I actually didn't know that! It seems to affect only when completing a file though.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
Hm, we are running into the old defaults.vim discussion again, however I am not convinced this change will really annoy people.
Let's take this as a test if people are complaining when moving default values from
defaults.vimto the C code. I am ready to roll this back, if this is really an issue.
The problem is that these embedded systems are upgraded over a period of time. So it will take time for this change to propagate to them. I am not sure how many of these users are part of this mailing list. So you may not get the compliant immediately.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I know, it's tricky. But of all the complaints on defaults.vim in the past, I did not remember 'wildmenu' part of it. And personally I hink it is a nice usability improvement (for new users).
Actually I wonder since we are talking about embedded systems, without runtime files, isn't that then rather a vi instead of vim , meaning it will behave as if compatible is set (in which case wildmenu wouldn't be set at all)?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
chdiza
the majority of user will want that. There isn't really a gain in disabling it by default and relegate it to defaults.vim.
wildmenu is really a popular option so I expect very minimal confusion. It will probably be annoying for the ones that for some reason don't like it but I think this is better for the majority of the users
These are simply asserted without any evidence whatsoever. No actual grounds for changing this are given. There is only "I like it and I shall simply assume that most people do too."
Please don't change options when no evidence is provided for why they should be changed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Please don't change options when no evidence is provided for why they should be changed.
Well, we are not really "changing" the options. Just moving from defaults.vim to the C core. They are supposed to be default anyhow.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
chdiza
You are changing it, because people with vimrcs who don't want that now have to change their vimrcs.
So I can rephrase: please don't make people change their vimrcs when nobody offers a reason.
Things being in a file called "defaults.vim" does not make them defaults. A default is what's hardcoded in. The fact that something appears in what amounts to a sample vimrc that is foisted upon people does not mean it should be hardcoded in.
The dumbest part of the whole defaults.vim business---and the entire business is unbelievably stupid---is the fact that the file is called "defaults.vim".
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Things being in a file called "defaults.vim" does not make them defaults. A default is what's hardcoded in.
I'll take that as a wish to move the rest of defaults.vim to the C core :)
It's okay to disagree, but please watch your tone.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dundargoc
@chdiza what type of "evidence" would it take to convince you this is a good idea?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
These are simply asserted without any evidence whatsoever. No actual grounds for changing this are given. There is only "I like it and I shall simply assume that most people do too."
Please don't change options when no evidence is provided for why they should be changed.
I don't think we will ever be able to gather data like this unless we go big-tech and add opt-out telemetry, which I doubt is something we want to do in Vim. At some point we do have to make a guess when we make changes like this and weigh the potential pros and cons. I don't think an absolute "we never change defaults" stance is useful, nor does Vim promise that even if it tries very hard to preserve backwards compatibility. I think in this case the cons is relatively minor. It may introduce some small differences in auto-complete behavior but I don't think this is anything as big as set mouse=a introduced a while ago (or should I not have brought up that big can of worms 😅).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
C.D. MacEachern
We don't have to guess, https://github.com/tpope/vim-sensible has been around a long time, it's settings debated (fun vim archeological readings btw) and battle tested through the years. And if GitHub stars signify anything, it's got ~5k stars. Neovim has implemented most these defaults, for further precedent and "evidence".
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
Please don't change options when no evidence is provided for why they should be changed.
Well, we are not really "changing" the options. Just moving from defaults.vim to the C core. They are supposed to be default anyhow.
defaults.vim is NOT the default, that most was (for) a std test env when '--clean'.
// if you really like to change something like those, perhaps release a new vim like feat vim compared to 'huge vim'.
or xxxvim was a feat vim already, you maybe not need to re-create a feat vim, aha~ 😄
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.