emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Experimentally unbind M-o on the trunk


From: Matt Armstrong
Subject: Re: Experimentally unbind M-o on the trunk
Date: Wed, 10 Feb 2021 11:10:00 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Alfred M. Szmidt" <ams@gnu.org>
>> Date: Wed, 10 Feb 2021 10:12:20 -0500
>> Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
>> 
>> Sorry, I atleast have a hard time taking these suggestion to remap
>> long standing keybindings randomly seriously, likewise suggestions
>> that users should just resort to M-x or binding them themselves.
>
> Can you explain why you are so worried about Emacs changing the
> default key bindings?  Given that it takes one line in your .emacs to
> restore any binding you care for, why argue so much about the
> defaults?
>
> This question also goes to everyone else in this long dispute who
> wants their precious key bindings preserved: why is such a long
> discussion needed when it is so easy to restore, in your init file, a
> binding you want preserved?

I'd even take it up another level. Why are we satisfied with Emacs'
current approach to exposing command based functionality to users? What
we've got with Emacs today is a key binding resource exhaustion problem.
But is moving bindings around the only way to address the problem?

What if having a key binding was just one possible way to make a command
easy and convenient to find and invoke. What if there were other equally
good ways, and we all thought it would be strange to bind a precious key
to a command if it were rarely used in practice?

Case in point: if a command isn't bound to a key it doesn't show up in
help, so there is this pressure to bind everything that could possibly
be useful to some person some day to some key. What if instead help
showed all the interactive commands provided by the mode? What if M-x
were smarter about highlighting mode specific commands?

Perhaps exploring these kinds of ideas would be useful.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]