bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20466: 25.0.50; REGRESSION in `isearch-mode-map': <backspace> is not


From: Stefan Monnier
Subject: bug#20466: 25.0.50; REGRESSION in `isearch-mode-map': <backspace> is not translated to DEL
Date: Fri, 01 May 2015 14:03:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>> What you're basically saying is that we should give up on the
>> function-key-map binding which remaps `backspace' to DEL.
> No, I'm saying it's unreliable, in the sense that a user who wants to
> customize DEL cannot rely on Backspace continue doing what DEL does.

Exactly: you're saying "it's unreliable, so just forget about ti and
always bind both keys".  And if both keys are bound in foo-map, then
both keys also need to be bound in any other bar-map if the two ever
happen to be active at the same time, so whoever follows your advice
will force other people to follow it as well.

The end result is that <backspace> will always be bound and the
function-key-map binding will be useless.

> We use stuff like function-key-map so that keys do what users expect,
> but only by default.  Once users start customizing keys, they cannot
> expect Backspace to always behave like DEL, not with the
> function-key-map method, which gives an explicit rebinding priority
> (as it must).

That's right.  But binding both <backspace> and DEL should only ever be
needed if you want to distinguish those two cases.  The purpose of the
function-key-map binding is to make sure that if you want the same
behavior for both, then you only need one binding (the one on DEL).

IOW for the function-key-map to be meaningful, we want to consider any
case where the user needs a redundant <backspace> binding, as
a bug/misfeature that we should try to fix.

> time.  I doubt if we want to do that, which leaves us with this
> dilemma that doesn't have a 100% reliable solution.

So far, we're pretty close to 100%, and I'd rather we try stay close to that.

> Whatever you do, my rule will always yield more reliable results.

And will break more other cases where people have followed the path
usually recommended (i.e. "only bind the DEL or TAB event unless you
want to distinguish the two").


        Stefan





reply via email to

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