bug#44611: Prefix arg for xref-goto-xref

[Eli Zaretskii]

> Cc: juri@linkov.net, joaotavora@gmail.com, 44611@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 23 Dec 2020 23:24:23 +0200
> 
> On 23.12.2020 22:30, Eli Zaretskii wrote:
> 
> > If you want to continue this discussion, please drop the attitude and
> > try to see the issue from my POV.  Otherwise I see no reason to
> > continue, as I've-been-there-done-that too many times.
> 
> Could you try seeing it from my POV?
> 
> This is the first time I've heard about a rule like that regarding key 
> bindings (and not just changes in existing functions, ones that would 
> break existing configurations and third-party code). If I knew about it, 
> I wouldn't have approved that key binding in the first place, those 4 
> years ago. Because "we can't change it later" is a pretty high standard 
> for acceptance.
> 
> And now it feels like you're like changing the rules under my feet. It's 
> not a good way to make a subsystem maintainer feel.

There is no new rule.  I apologize if something I said could be
interpreted that way.

There's only one rule: not to make backward-incompatible changes
without a very good reason.  That is not limited to changes in
functions and APIs, key bindings are definitely included.  In fact, I
think incompatible changes in key bindings are even worse than changes
in code, since they might go against muscle memory, and nothing can
fix that except a long and painful process of unlearning.

I've reviewed all the NEWS since v24.1, and found only one
incompatible change in key bindings -- which started by declaring the
existing binding obsolete.  So I think we change key bindings in
incompatible ways only very rarely and carefully, and that is a Good
Thing.

Given the single precedent I found, I'm fine with declaring the
current binding of TAB obsolete and providing a replacement for it
('b'? 'q'?), so that we could replace it in some future version after
28, if that is okay with you and Juri.