Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Your stats are off.

Any evidence to back this claim?  Have you, perhaps, developed strong
opinions on the subject, more worthy of consideration than a
questionable identification of persons as problems?  Is it really wise
to steer this discussion further off course towards impugning persons,
and in short order, specific persons among us?

> No it wasn't.

I'll give one example of what is _NOT_ an acknowledgement:

> ...I haven't seen why in this case binding these keys is a
> particularly bad idea. The original argument is that providing these
> bindings would somehow override user customization. They
> won't. There's no deprivation of user customization, so the "scarcity"
> of arrow key bindings is irrelevant. Now the objection is over
> "clutter"? Does an arrow key binding somehow create more clutter than
> some other binding? There's nothing special about these bindings.

"I haven't heard you."  "What you said is false."  "You're WRONG."
"You're moving the goalposts."  "There is NOTHING of substance to what
you have said."

And one more:

> 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.

"You're arguing TOO GENERALLY, i.e. WRONG!"  "Therefore, I think you're
wrong."  [Totally immaterial and accomplished facts which may or may not
be reexamined in a different light with the benefit of hindsight.]

And, the grand finale, the snub to end all snubs:

>> This is just one, and by far not the most compelling, of many
>> objections to introducing new default keybindings, but one of which a
>> recent example comes to mind: C-x x u has for many years been bound
>> in my sessions to a command that deletes a buffer's undo list,
>> usually in the interests of security.  The consequences of a
>> stranger's unsuspectingly typing the same to invoke rename-uniquely
>> might easily have been catastrophic.
>
> This attitude is why Doom Emacs exists. A live software project is one
> that changes. A dead one prioritizes stasis over user experience.
>
> Nothing we're talking about here will disturb your custom
> keybindings. Your experience will work just as it did before.

In what sense does this even purport to address the scenario I
illustrated in such particular terms?

Now, then, consider:

  https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00926.html

How many of those issues which I raised have since been addressed?  If
they have, where are these answers, and what is their relation to my
questions?