emacs-devel
[Top][All Lists]
Advanced

[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 22:48:24 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Daniel Colascione <dancol@dancol.org> writes:

> You're overthinking this. C-x 4 is for stuff relating to windows. Of
> course that's the right place to put window movement commands. There's
> no other logical place.

Who said so?  I see nothing to this effect in ctl-x-4-map or its
(vanishingly scant) documentation, which map is composed entirely of
commands answering to the description I gave.

> You can choose to make that binding. I don't think it's a good
> default. Adding a reasonable default does not hurt you.

It does.  I explained how it does, and you declined to acknowledge my
explanation, or, if you disagreed, openly state your grounds for
disagreement.

> Ffap is a fringe feature. Window movement is fundamental to the whole
> system.

A fringe feature with a VC history thrice as large as windmove's,
and 1.5x as many mentions in help-gnu-emacs.  Window movement is
a fundamental requirement that is perfectly satisfied by other-window
and mouse commands, and the paucity of windmove users speaks for itself,
when they are fewer than those of such a "fringe feature" as ffap.

> Again, you're making a general argument against adding any new
> bindings whatsoever.  I don't think that's a good thing.  The very
> same argument would have applied to the vc and project default
> bindings.

It is a general argument to be _circumspect_ in introducing new
keybindings.  The question of relevance is, Whether a proposed binding
is of sufficient importance or located in a sufficiently discreet
position to nullify the disadvantages cited in the argument.  Windmove
is not, nor are the proposed keybindings.

> So now we're going from keybindings to sociology? K.

What I see is that I argue in good faith and you respond by quibbling
sardonically.  Hardly a shining example of good software development
practice.

>>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.
  --------------------------------------------------------------
>
> Yes they have. Check the thread. In fact, it was Stefan who
> resurrected the thread in the first place.

Nowhere has Stefan M mentioned which bindings he personally uses for
Windmove.

> You are, in fact, though ,making a general argument, then suggesting
> it applies only to this one matter.

You are, rather, dealing in absolutes.  I am not responsible for your
failing to understand that, when, where, and how one set of
disadvantages might be outweighed by a corresponding set of advantages.

> That's called "special pleading" and is a structurally invalid kind of
> discourse.

Special pleading is claiming an unsubstantiated exception to a general
rule.  This, by contrast, is the application of a general rule to a
specific issue to which it is material.

> I think Doom Emacs and Spacemacs are in bounds. They exist because
> core Emacs has been insufficiently responsive to needs of real world
> users, and this thread is this problem in microcosm.

More oratory.

> There is a difference between changing an existing binding (e.g. C-z)
> and installing a new binding where none currently exists. Merging the
> two scenarios doesn't lead the conversation in a good place.

It is rather the users who are affected by this distinction than
ourselves.  But you are conflating the scenario where the user creates a
binding in an unoccupied location with that where we do so, after which,
and for the users, that location is removed from the scope of the
former.


reply via email to

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