[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: new default bindings for winner and windmove
From: |
Po Lu |
Subject: |
Re: Proposal: new default bindings for winner and windmove |
Date: |
Wed, 26 Jun 2024 21:53:20 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Daniel Colascione <dancol@dancol.org> writes:
> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Jeremy Bryant <jb@jeremybryant.net>
>>> Cc: Po Lu <luangruo@yahoo.com>, dancol@dancol.org, acm@muc.de,
>>> stefankangas@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>> Date: Tue, 25 Jun 2024 22:26:47 +0100
>>>
>>> 1.
>>> I also find that C-x 4 is indeed logical, which makes it easier to remember
>>>
>>> 2.
>>> C-x 4 .. works on the terminal/console. This is important for
>>> preserving functionality of Emacs.
>>
>>I still hope that someone will tell what is exactly the request here,
>>given that windmove-mode is on by default and its commands are
>>autoloaded.
>
> To be clear, my proposal is to bind C-x 4 <arrow> in the default
> global keymap to the corresponding directional windmove commands and
> to bind the shifted versions of these keys to the state swapping
> versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT
> should move left.
C-x 4 is not for window management commands, but for commands that
influence which window the results of a future command are to be
displayed in, and it has been so for a substantial period, so that users
won't bat an eyelid before creating bindings keeping to this pattern.
As such, it is perfectly logical to bind, say, ffap-other-window, in
this keymap, but not every command that marginally relates to window
management.
Windmove is not so important as ffap, to judge by the number of
instances of each in the archives of help-gnu-emacs, and therefore
default keybindings for its commands can only be less justified. If
they were, there could also easily be a place for them far more rational
and less disruptive than C-x 4. Extending the domain of existing
keymaps is, whatever you think, a source of variance between the
expectations of old and new users, and deprives users of room for custom
keybindings, again, since they experience a natural reluctance to
contradict the judgement of their superiors, expressed in the defaults
they decide, so that the obligation of exercising this privilege wisely
and sparingly devolves on _ourselves_, who should constantly be at pains
to earn and deserve this respect. With all due respect, you are just
one user, and though many have concurred with your choice, yet none of
them have previously created the same set of bindings as yours. This
implies that the question of establishing default bindings for Windmove,
and more so your preferences for these bindings, was profoundly
uninteresting to everyone but yourself, and should not even have been
raised until it had attracted some more interest.
So perhaps you might understand why it is upsetting to see our arguments
deflected with some vague dismissal of "general embargoes", or oratory
against "stasis", and appeals to such absolutely irrelevant matters as
Doom Emacs, or because it amounts to declaring that "users ought never
to rebind keys at all." Reverting to these general proclamations of
triumph gives the impression of being disinterested in constructive
communication and trying to understand your opponents' positions, and
being rather more inclined to simply heckle opponents into silence if
agreement is impossible. Seriously, ask yourself this simple question,
if the existence of default keybindings are truly no deterrent to
customization, why is cua-mode necessary for the majority of its users,
who simply need C-z rebound to undo and C-x to kill-region? And why
will the introduction of new keybindings not produce new habits in
users, or, why will such habits not be out of place in sessions where
those key sequences had long been bound otherwise? But no, we must be
treated to oratory composed of allusions to Doom Emacs, Emacs's need to
remain competitive in the 21st century, and other verbiage. For shame!
- Re: Proposal: new default bindings for winner and windmove, (continued)
- Re: Proposal: new default bindings for winner and windmove, Joel Reicher, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Eli Zaretskii, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Alan Mackenzie, 2024/06/26
- RE: [External] : Re: Proposal: new default bindings for winner and windmove, Drew Adams, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Stefan Monnier, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Alan Mackenzie, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove,
Po Lu <=
- Re: Proposal: new default bindings for winner and windmove, Daniel Colascione, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Po Lu, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Stefan Monnier, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Po Lu, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Alan Mackenzie, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Augusto Stoffel, 2024/06/27
- RE: [External] : Re: Proposal: new default bindings for winner and windmove, Drew Adams, 2024/06/26
- Re: Proposal: new default bindings for winner and windmove, Daniel Colascione, 2024/06/23
- Re: Proposal: new default bindings for winner and windmove, Po Lu, 2024/06/23
- Re: Proposal: new default bindings for winner and windmove, Daniel Colascione, 2024/06/23