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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  20466@debbugs.gnu.org
> Date: Thu, 30 Apr 2015 19:12:07 -0400
> 
> > The "why" part was answered by Artur, who pointed to the bug report
> > which triggered that change.
> [...]
> > I learned long ago that if you want to change the binding of DEL, you
> > had better changed the binding of Backspace accordingly at the same time,
> 
> I strongly disagree here: following this kind of rule is what caused the
> problem in the first place.

No, following the rule would have prevented it.  The user in question
didn't customize both keys, he customized only DEL.

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

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

The root problem underlying this is that some keyboards have only DEL,
some have only Backspace, and some have both.  If we want both keys to
always behave the same, we should treat them as the same key, all the
time.  I doubt if we want to do that, which leaves us with this
dilemma that doesn't have a 100% reliable solution.

> Clearly, this bug report shows that this remapping is harder to handle
> right in the case of isearch-mode-map.
> 
> I think The Right Way to handle it is to bind (in isearch-mode-map)
> `backspace' to `undefined' (so it hides bindings in lower-precedence
> maps, but still lets the function-key-map remapping take place).

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