[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.
- Re: Experimentally unbind M-o on the trunk, (continued)
- Re: Experimentally unbind M-o on the trunk, Alfred M. Szmidt, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, Eli Zaretskii, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, Alfred M. Szmidt, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, Eli Zaretskii, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, Matt Armstrong, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, Alan Mackenzie, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, Eli Zaretskii, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, andrés ramírez, 2021/02/10
- RE: [External] : Re: Experimentally unbind M-o on the trunk, Drew Adams, 2021/02/10
- Re: Experimentally unbind M-o on the trunk, Jean Louis, 2021/02/11
- Re: Experimentally unbind M-o on the trunk,
Matt Armstrong <=
- Re: Experimentally unbind M-o on the trunk, Lars Ingebrigtsen, 2021/02/10
- Smarter M-x that filters on major-mode, Stefan Kangas, 2021/02/10
- Re: Smarter M-x that filters on major-mode, Stefan Monnier, 2021/02/10
- Re: Smarter M-x that filters on major-mode, Yuan Fu, 2021/02/11
- RE: [External] : Re: Smarter M-x that filters on major-mode, Drew Adams, 2021/02/11
- RE: [External] : Re: Smarter M-x that filters on major-mode, Drew Adams, 2021/02/11
- Re: Smarter M-x that filters on major-mode, Lars Ingebrigtsen, 2021/02/11
- Re: Smarter M-x that filters on major-mode, Lars Ingebrigtsen, 2021/02/11
- Re: Smarter M-x that filters on major-mode, Lars Ingebrigtsen, 2021/02/11
- Re: Smarter M-x that filters on major-mode, Eli Zaretskii, 2021/02/11