[vim/vim] defaults: set showcmd by default (PR #16149)

34 views
Skip to first unread message

Luca Saccarola

unread,
Dec 1, 2024, 4:46:28 PM12/1/24
to vim/vim, Subscribed

This PR make showcmd on by default when using vim.

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/16149

Commit Summary

  • a7392e0 defaults: set showcmd by default

File Changes

(3 files)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/16149@github.com>

zeertzjq

unread,
Dec 1, 2024, 6:20:32 PM12/1/24
to vim/vim, Subscribed

In os_unix.txt there is:

For historic reasons terminal updating under Unix is expected to be slow (e.g.
serial line terminal, shell window in suntools), the 'showcmd' and 'ruler'
options are off by default.  If you have a fast terminal, try setting them
on: >
	set showcmd ruler

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

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/16149/c2510298432@github.com>

Yegappan Lakshmanan

unread,
Dec 1, 2024, 10:30:05 PM12/1/24
to vim/vim, Subscribed

Making the "showcmd" option set as the default is not backward compatible. For example, I have a .vimrc file, so the defaults.vim
file is not used. In my case, now "showcmd" will be enabled by default and I need to explicitly disable it in the .vimrc file.
I don't like these recent changes to move the settings from defaults.vim file to the Vim core (this is going to surprise a lot of
long-time Vim users).

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

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/16149/c2510489474@github.com>

Christian Brabandt

unread,
Dec 2, 2024, 3:55:42 AM12/2/24
to vim/vim, Subscribed

My idea was to gradually promote settings that Bram thought to be defaults back to the C core to simplify defaults.vim. My intentions was to keep settings behind some if conditions inside defaults.vim but migrate other settings to the C core, since I did not hear any complaints when they were enabled with defaults.vim. Perhaps we should not touch showcmd ruler and possibly scrolloff then. I don't intend to touch the mouse setting, that was too controversial anyhow, but at least ttytimeout may make sense I think.

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

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/16149/c2510926347@github.com>

Luca Saccarola

unread,
Dec 2, 2024, 6:10:28 AM12/2/24
to vim/vim, Subscribed

My main idea is to retire defaults.vim entirely in favor of a more user friendly on boarding.

To my understanding, defaults.vim was born from the desire to make the defaults more "sensible" but without changing settings of long time users. Unfortunately the current solution is really confusing for new users and can be annoying to some.

My plan is:

  1. Move the uncontroversial parts and clear UX improvements to the C core
  2. Renovate the vimrc_example
  3. Document better the unboarding progress in the docs
  4. Making some youtube videos / blog posts about this
  5. Put a clear indication in the splashscreen on what to do when trying to customize vim

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

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/16149/c2511238999@github.com>

Luca Saccarola

unread,
Dec 2, 2024, 6:11:09 AM12/2/24
to vim/vim, Subscribed

Closed #16149.

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

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/16149/issue_event/15491301209@github.com>

Gary Johnson

unread,
Dec 2, 2024, 12:07:02 PM12/2/24
to reply+ACY5DGEV6FV2Z2V5WN...@reply.github.com, vim...@googlegroups.com
On 2024-12-02, Christian Brabandt wrote:
> My idea was to gradually promote settings that Bram thought to be defaults back
> to the C core to simplify defaults.vim. My intentions was to keep settings
> behind some if conditions inside defaults.vim but migrate other settings to the
> C core, since I did not hear any complaints when they were enabled with
> defaults.vim. Perhaps we should not touch showcmd ruler and possibly scrolloff
> then. I don't intend to touch the mouse setting, that was too controversial
> anyhow, but at least ttytimeout may make sense I think.

I would imagine you didn't hear any complaints about the settings in
defaults.vim because very few if any readers of this list use
defaults.vim. The only people I can think of who would use
defaults.vim are those who haven't used Vim long enough to have
created their own vimrc and have no expectations of Vim's behavior.

I haven't cared about what has gone into defaults.vim because
I don't use it. I haven't cared too much about some of the internal
defaults being changed because I have those settings in my vimrc
already and I didn't have good arguments for the old values being
better. "Backwards compatibility" seemed like a weak argument for
most of them. Now, I feel that the changes to Vim's internal
defaults are getting out of hand, that they're worse violations of
backwards compatibility, and that they're being driven by the
personal preferences of a few.

Regards,
Gary

vim-dev ML

unread,
Dec 2, 2024, 12:07:32 PM12/2/24
to vim/vim, vim-dev ML, Your activity

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

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/16149/c2512183871@github.com>

Christian Brabandt

unread,
Dec 2, 2024, 12:52:15 PM12/2/24
to vim/vim, vim-dev ML, Comment

Alright, it seems we cannot really touch/update any defaults at all, there is too much resistance to change it. So far we have only touched 'history' (increased to 200 for both compatible and non-compatible mode) and updated 'backspace' (to include 'indent,eol,start' in non-compatible mode), both of which seem clear (UX-) enhancements.

But I'll refrain from touching any defaults ... ever again. So we will have to live with the half-broken defaults.vim 🤷

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: <vim/vim/pull/16149/c2512281643@github.com>

Luca Saccarola

unread,
Dec 2, 2024, 3:11:00 PM12/2/24
to vim/vim, vim-dev ML, Comment

But I'll refrain from touching any defaults ... ever again. So we will have to live with the half-broken defaults.vim 🤷

It really sucks but it is what it is...

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: <vim/vim/pull/16149/c2512686251@github.com>

Maxim Kim

unread,
Dec 2, 2024, 5:51:16 PM12/2/24
to vim/vim, vim-dev ML, Comment

So we will have to live with the half-broken defaults.vim

Or we can make a decision to break vim compat for a greater good -- just remove defaults.vim at all.

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

You are receiving this because you commented.Message ID: <vim/vim/pull/16149/c2513143921@github.com>

Ajit-Thakkar

unread,
Dec 2, 2024, 6:20:30 PM12/2/24
to vim/vim, vim-dev ML, Comment

@chrisbra choosing defaults is always contentious. Please don't take criticism personally. FWIW, I too think the half-broken defaults.vim needs to be fixed.

It could simply be removed. It could be moved to vimrc_example. That would essentially take us back to vim7.

Or the defaults.vim options could be moved to the c core and set/unset as a group by introducing a new Boolean option, say vim8_defaults.

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

You are receiving this because you commented.Message ID: <vim/vim/pull/16149/c2513179442@github.com>

Reply all
Reply to author
Forward
0 new messages