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

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

[Drew Adams]

> The "why" part was answered by Artur, who pointed to the bug report
> which triggered that change.

That reports a problem.  It doesn't imply that the chosen fix is
the best fix.

> > It is an incompatible change, and I see nothing in NEWS about it.
> 
> It's not really incompatible, but I agree that it would be good to
> document the change, although I don't believe we document changes in
> keybindings in general.

> if you want to change the binding of DEL, you had better changed
> the binding of Backspace accordingly at the same time, because
> there's no guarantee Backspace will not be bound in any particular
> mode.  So why you are showing a use case that violates this simple
> rule?

That's certainly a useful rule for users to keep in mind, and it
applies to all key translations.  But it has not been necessary
in the past to take it into account for Isearch.  That's all.

Dunno whether such a rule/reminder is mentioned in the Emacs docs,
or even where it should be mentioned (key translations are not
something that most users read about).  Even if it were mentioned
in the doc about key translations, I doubt that would help most
users who might stumble on this.  Think of the many users who
have asked about shifted keys (a similar translation gotcha).

FWIW: I don't mind this change, personally (I don't bind `DEL' in
`isearch-mode-map').  I'm just pointing out that it might not be
expected, and that some users will likely scratch their heads
trying to figure out what's going on.

What the best thing to do about it is now (maybe nothing?), I
don't know.

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

[Drew Adams]

This regression was apparently introduced in Emacs 24.4.

(define-key isearch-mode-map (kbd "DEL") 
            (lambda () (interactive) (message "@@@@@@@@@@@@@@@@")))

During Isearch, hit the Backspace key.  `DEL' is not used, so the
message is not seen.  `isearch-mode-map' shows that `DEL' is correctly
bound to the above command, but `<backspace>' is bound to
`isearch-delete-char'.  It is not translated to `DEL', as is the case in
Emacs generally (still), but it instead now has its own explicit binding
in `isearch-mode-map'.

Why?  This is an unexpected (and unnecessary?) obstacle for users.
It is an incompatible change, and I see nothing in NEWS about it.
Was it an oversight or intentional?

In Emacs prior to 24.4, the message is shown, and `isearch-mode-map'
shows that `DEL' is bound to the above command and there is no binding
for `<backspace>'.  Because there is no binding for it, it gets
translated to `DEL' (as is true in Emacs generally, even in 24.4+).

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

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

[Artur Malabarba]

Looking at the commit message for that change, it points at this bug
report: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16342

It looks valid to me. Isearch doesn't know where it's being run so it
needs to ensure backspace is bound to the right key. I suppose it
could do some keybind checking and only bind backspace if it wouldn't
already be translated to DEL, but then this reported issue would still
happen on these cases (and it would be even harder for the user to
figure out because it would only happen on some buffers).

2015-04-30 6:19 GMT+01:00 Drew Adams <drew.adams@oracle.com>:
> This regression was apparently introduced in Emacs 24.4.
>
> (define-key isearch-mode-map (kbd "DEL")
>             (lambda () (interactive) (message "@@@@@@@@@@@@@@@@")))
>
> During Isearch, hit the Backspace key.  `DEL' is not used, so the
> message is not seen.  `isearch-mode-map' shows that `DEL' is correctly
> bound to the above command, but `<backspace>' is bound to
> `isearch-delete-char'.  It is not translated to `DEL', as is the case in
> Emacs generally (still), but it instead now has its own explicit binding
> in `isearch-mode-map'.
>
> Why?  This is an unexpected (and unnecessary?) obstacle for users.
> It is an incompatible change, and I see nothing in NEWS about it.
> Was it an oversight or intentional?
>
> In Emacs prior to 24.4, the message is shown, and `isearch-mode-map'
> shows that `DEL' is bound to the above command and there is no binding
> for `<backspace>'.  Because there is no binding for it, it gets
> translated to `DEL' (as is true in Emacs generally, even in 24.4+).
>
> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
>  of 2014-10-20 on LEG570
> Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
>  `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'
>
>
>

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

[Eli Zaretskii]

> Date: Wed, 29 Apr 2015 22:19:48 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> This regression was apparently introduced in Emacs 24.4.
> 
> (define-key isearch-mode-map (kbd "DEL") 
>             (lambda () (interactive) (message "@@@@@@@@@@@@@@@@")))
> 
> During Isearch, hit the Backspace key.  `DEL' is not used, so the
> message is not seen.  `isearch-mode-map' shows that `DEL' is correctly
> bound to the above command, but `<backspace>' is bound to
> `isearch-delete-char'.  It is not translated to `DEL', as is the case in
> Emacs generally (still), but it instead now has its own explicit binding
> in `isearch-mode-map'.
> 
> Why?  This is an unexpected (and unnecessary?) obstacle for users.

The "why" part was answered by Artur, who pointed to the bug report
which triggered that change.

> It is an incompatible change, and I see nothing in NEWS about it.

It's not really incompatible, but I agree that it would be good to
document the change, although I don't believe we document changes in
keybindings in general.

May I ask what kind of real-life use case is behind this?  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, because
there's no guarantee Backspace will not be bound in any particular
mode.  So why you are showing a use case that violates this simple
rule?

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

[Stefan Monnier]

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

What you're basically saying is that we should give up on the
function-key-map binding which remaps `backspace' to DEL.

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


        Stefan

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.

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

[Stefan Monnier]

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

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@oracle.com,  20466@debbugs.gnu.org
> Date: Fri, 01 May 2015 14:03:26 -0400
> 
> >> 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".

Or don't bind either, in which case you don't need to "just forget
about it".

> 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

You lost me.  What do you mean by "active at the same time"?

> so whoever follows your advice will force other people to follow it
> as well.

Good advice is like that, yes.

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

Not if these keys are left at their default bindings, no.

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

Which doesn't work if the mode binds Backspace.

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

But this is exactly what the OP did, and look where it got him.

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

[Stefan Monnier]

I installed the proposed patch, which should fix this bug, without
re-introducing the other bug.


        Stefan


> You lost me.  What do you mean by "active at the same time"?

Both appear in `current-active-maps' in some buffer at some point.
(e.g. one binding in a minor mode, another in a major-mode)

>> so whoever follows your advice will force other people to follow it
>> as well.

> Good advice is like that, yes.

>> The end result is that <backspace> will always be bound and the
>> function-key-map binding will be useless.
> Not if these keys are left at their default bindings, no.

That's only if noone bound anything, in which case noone followed
neither's advice anyway.  Not a very enlightening case.

>> 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).
> Which doesn't work if the mode binds Backspace.

Which mode?  And presumably if a keymap binds Backspace it's
specifically because it wants backspace to behave differently from DEL,
in which case it's fine if function-key-map is not used.

>> > 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").
> But this is exactly what the OP did, and look where it got him.

That's because the binding we used in isearch.el followed your advice
rather than mine ;-)