A bug, I think, in key-binding

A bug, I think, in key-binding

[David Kastrup]

Hi, we have

    read-key-sequence is a built-in function in `src/keyboard.c'.
    (read-key-sequence PROMPT &optional CONTINUE-ECHO DONT-DOWNCASE-LAST
    CAN-RETURN-SWITCH-FRAME COMMAND-LOOP)

    Read a sequence of keystrokes and return as a string or vector.
    The sequence is sufficient to specify a non-prefix command in the
    current local and global maps.

    [...]

    If the key sequence starts with a mouse click, then the sequence is read
    using the keymaps of the buffer of the window clicked in, not the buffer
    of the selected window as normal.

    [...]

`read-key-sequence', although the DOC string does not mention it, will
also substitute any mouse-activated maps for the buffer-local maps, if
they are present and a click event is used.

But if we take a look at `key-binding':

    key-binding is a built-in function in `src/keymap.c'.
    (key-binding KEY &optional ACCEPT-DEFAULT NO-REMAP)

    Return the binding for command KEY in current keymaps.
    KEY is a string or vector, a sequence of keystrokes.

    [...]

we will find that the same expression "current keymaps" suddenly fails
to include mouse-activated maps even for click events.

As a result, you can't reliably feed the output of `read-key-sequence'
into `key-binding': the meaning differs.

I think this is a mistake.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A bug, I think, in key-binding

[Richard Stallman]

    `read-key-sequence', although the DOC string does not mention it, will
    also substitute any mouse-activated maps for the buffer-local maps, if
    they are present and a click event is used.

What do you mean by "mouse-activated maps"?  Do you mean keymaps that
come from properties that apply to the character that was clicked on?
The way we describe that feature is that the location of the click
overrides point for choosing the character whose properties should be used.

    But if we take a look at `key-binding':

    we will find that the same expression "current keymaps" suddenly fails
    to include mouse-activated maps even for click events.

That is true.  But I think key-binding MUST do what it now does.
That is an essential primitive for accessing keymaps.

Perhaps we should have a function to do lookup on a key sequence
just the same way the command loop does.  That can be written in Lisp;
it just has to see if the first event is a mouse even, and move point
there inside save-excursion.

What do you think of this solution?  Of course, the documentation should
be clarified in various places as well.

Re: A bug, I think, in key-binding

[Stefan Monnier]

> That is true.  But I think key-binding MUST do what it now does.
> That is an essential primitive for accessing keymaps.

I don't think the two are incompatible: currently, key-binding does not work
if one of the keys in the sequence is an event (rather than just a char or
a symbol), so we would just need to extend it so it also works with events.

The only trick might be to distinguish events from Lucid-style key
specs like (control c).

> Perhaps we should have a function to do lookup on a key sequence
> just the same way the command loop does.  That can be written in Lisp;
> it just has to see if the first event is a mouse even, and move point
> there inside save-excursion.

Moving point is not sufficient if the click is on an image-map, or on
before-string.  I'd rather reuse the C code if at all possible rather than
try to mimick it in elisp (unless we can completely replace the C version
with the elisp version).


        Stefan

Re: A bug, I think, in key-binding

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     `read-key-sequence', although the DOC string does not mention it, will
>     also substitute any mouse-activated maps for the buffer-local maps, if
>     they are present and a click event is used.
>
> What do you mean by "mouse-activated maps"?  Do you mean keymaps that
> come from properties that apply to the character that was clicked
> on?

Keymaps on display properties, before-string properties and
after-string properties.

> The way we describe that feature is that the location of the click
> overrides point for choosing the character whose properties should
> be used.

I was not able to glean that from the DOC string.

>     But if we take a look at `key-binding':
>
>     we will find that the same expression "current keymaps" suddenly fails
>     to include mouse-activated maps even for click events.
>
> That is true.  But I think key-binding MUST do what it now does.
> That is an essential primitive for accessing keymaps.

So it is quite lamentable that its current implementation does not do
the trick.  The command loop could not get implemented using it.
Instead, read-key-sequence stashes the looked-up command away in a
secret internal variable where the command loop retrieves it.  While
it is efficient to avoid the double lookup (read-key-sequence has to
know how to combine primitive events to a sequence, and that requires
the maps), it also makes key-binding pretty much a sham: it is neither
used nor usable for its central purpose in the command loop.

> Perhaps we should have a function to do lookup on a key sequence
> just the same way the command loop does.  That can be written in
> Lisp; it just has to see if the first event is a mouse even, and
> move point there inside save-excursion.
>
> What do you think of this solution?

It is not sufficient to relocate point temporarily (I believe this
might actually already be done), since the maps of mouse clicks depent
on the actual screen position, not just the point position, of a mouse
click.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A bug, I think, in key-binding

[Richard Stallman]

    I don't think the two are incompatible: currently, key-binding does not work
    if one of the keys in the sequence is an event (rather than just a char or
    a symbol),

Yes, it does work in that case.  (I just tested it.)

    > Perhaps we should have a function to do lookup on a key sequence
    > just the same way the command loop does.  That can be written in Lisp;
    > it just has to see if the first event is a mouse even, and move point
    > there inside save-excursion.

    Moving point is not sufficient if the click is on an image-map, or on
    before-string.  I'd rather reuse the C code if at all possible rather than
    try to mimick it in elisp (unless we can completely replace the C version
    with the elisp version).

That is a valid point; this needs to be implemented at C level.

Perhaps an optional argument to key-binding is the way to do it.
Would you like to implement that?

Re: A bug, I think, in key-binding

[Richard Stallman]

[I sent this message a week ago but did not get a response.]

    I don't think the two are incompatible: currently, key-binding does not work
    if one of the keys in the sequence is an event (rather than just a char or
    a symbol),

Yes, it does work in that case.  (I just tested it.)

    > Perhaps we should have a function to do lookup on a key sequence
    > just the same way the command loop does.  That can be written in Lisp;
    > it just has to see if the first event is a mouse even, and move point
    > there inside save-excursion.

    Moving point is not sufficient if the click is on an image-map, or on
    before-string.  I'd rather reuse the C code if at all possible rather than
    try to mimick it in elisp (unless we can completely replace the C version
    with the elisp version).

That is a valid point; this needs to be implemented at C level.

Perhaps an optional argument to key-binding is the way to do it.
Would you like to implement that?

Re: A bug, I think, in key-binding

[Stefan Monnier]

>     Moving point is not sufficient if the click is on an image-map, or on
>     before-string.  I'd rather reuse the C code if at all possible rather than
>     try to mimick it in elisp (unless we can completely replace the C version
>     with the elisp version).

> That is a valid point; this needs to be implemented at C level.

> Perhaps an optional argument to key-binding is the way to do it.
> Would you like to implement that?

Not now at least, no,


        Stefan

Re: A bug, I think, in key-binding

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [I sent this message a week ago but did not get a response.]
>
>     I don't think the two are incompatible: currently, key-binding
>     does not work if one of the keys in the sequence is an event
>     (rather than just a char or a symbol),
>
> Yes, it does work in that case.  (I just tested it.)

But it does not adapt the searched maps accordingly.

>     > Perhaps we should have a function to do lookup on a key
>     > sequence just the same way the command loop does.  That can be
>     > written in Lisp; it just has to see if the first event is a
>     > mouse even, and move point there inside save-excursion.
>
>     Moving point is not sufficient if the click is on an image-map,
>     or on before-string.  I'd rather reuse the C code if at all
>     possible rather than try to mimick it in elisp (unless we can
>     completely replace the C version with the elisp version).
>
> That is a valid point; this needs to be implemented at C level.
>
> Perhaps an optional argument to key-binding is the way to do it.
> Would you like to implement that?

Actually, I don't think we should need an optional argument at all:
when feeding an event into key-binding (which is defined to use all
local maps), one would likely rather have the same maps apply as
read-key-sequence has.

An optional argument might be handy in special cases.

We have currently

    key-binding is a built-in function in `C source code'.
    (key-binding KEY &optional ACCEPT-DEFAULT NO-REMAP)

    Return the binding for command KEY in current keymaps.
    KEY is a string or vector, a sequence of keystrokes.
    The binding is probably a symbol with a function definition.

    Normally, `key-binding' ignores bindings for t, which act as default
    bindings, used when nothing else in the keymap applies; this makes it
    usable as a general function for probing keymaps.  However, if the
    optional second argument ACCEPT-DEFAULT is non-nil, `key-binding' does
    recognize the default bindings, just as `read-key-sequence' does.

    Like the normal command loop, `key-binding' will remap the command
    resulting from looking up KEY by looking up the command in the
    current keymaps.  However, if the optional third argument NO-REMAP
    is non-nil, `key-binding' returns the unmapped command.

    [back]

I think it would be nice to have

    key-binding is a built-in function in `C source code'.
    (key-binding SEQUENCE &optional ACCEPT-DEFAULT NO-REMAP LOCATION)

    Return the binding for command SEQUENCE in current keymaps.
    SEQUENCE is a string or vector, a sequence of keystrokes,
    or an event to look up.
    The binding is probably a symbol with a function definition.

    Normally, `key-binding' ignores bindings for t, which act as default
    bindings, used when nothing else in the keymap applies; this makes it
    usable as a general function for probing keymaps.  However, if the
    optional second argument ACCEPT-DEFAULT is non-nil, `key-binding' does
    recognize the default bindings, just as `read-key-sequence' does.

    Like the normal command loop, `key-binding' will remap the command
    resulting from looking up KEY by looking up the command in the
    current keymaps.  However, if the optional third argument NO-REMAP
    is non-nil, `key-binding' returns the unmapped command.

    If SEQUENCE is a mouse event, the current maps may depend on
    whether the event occured above mouse-sensitive areas.  If
    LOCATION is an event, the current maps will be selected according
    to LOCATION rather than SEQUENCE.  This can be used for looking up
    artificial bindings like `follow-link'.  If LOCATION is non-nil
    but not an event, the current maps will not be mouse-sensitive
    even when SEQUENCE is an event.

    [back]

Ok, this is a bit verbose, but it would reflect what I'd consider
useful, namely that

(key-binding (read-key-sequence "Press anything))

will look up the keys in the same maps where read-key-sequence got
them.  Yes, it would be a change to the current behavior even when not
using the "LOCATION" argument.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A bug, I think, in key-binding

[Richard Stallman]

    Moving point is not sufficient if the click is on an image-map, or on
    before-string.  I'd rather reuse the C code if at all possible rather than
    try to mimick it in elisp (unless we can completely replace the C version
    with the elisp version).

That is a valid point; this needs to be implemented at C level.
Perhaps an optional argument to key-binding is the way to do it.

Would someone like to implement this?

Re: A bug, I think, in key-binding

[Richard Stallman]

    >     > Perhaps we should have a function to do lookup on a key
    >     > sequence just the same way the command loop does.  That can be
    >     > written in Lisp; it just has to see if the first event is a
    >     > mouse even, and move point there inside save-excursion.

    ...
    > Perhaps an optional argument to key-binding is the way to do it.
    > Would you like to implement that?

    Actually, I don't think we should need an optional argument at all:
    when feeding an event into key-binding (which is defined to use all
    local maps), one would likely rather have the same maps apply as
    read-key-sequence has.

I agree that is the cleanest design, but I was worried about the
incompatible change it involves.

So I just checked all the calls to `key-binding' and `XYZ-key-binding'
in the Emacs sources (except those in viper).  It seems that this
change would hardly ever cause a bug, and often might fix a bug.  So I
am now in favor of your proposal.

Would someone please implement this, then ack this message?


    key-binding is a built-in function in `C source code'.
    (key-binding SEQUENCE &optional ACCEPT-DEFAULT NO-REMAP LOCATION)

    Return the binding for command SEQUENCE in current keymaps.
    SEQUENCE is a string or vector, a sequence of keystrokes,
    or an event to look up.
    The binding is probably a symbol with a function definition.

    Normally, `key-binding' ignores bindings for t, which act as default
    bindings, used when nothing else in the keymap applies; this makes it
    usable as a general function for probing keymaps.  However, if the
    optional second argument ACCEPT-DEFAULT is non-nil, `key-binding' does
    recognize the default bindings, just as `read-key-sequence' does.

    Like the normal command loop, `key-binding' will remap the command
    resulting from looking up KEY by looking up the command in the
    current keymaps.  However, if the optional third argument NO-REMAP
    is non-nil, `key-binding' returns the unmapped command.

    If SEQUENCE is a mouse event, the current maps may depend on
    whether the event occured above mouse-sensitive areas.  If
    LOCATION is an event, the current maps will be selected according
    to LOCATION rather than SEQUENCE.  This can be used for looking up
    artificial bindings like `follow-link'.  If LOCATION is non-nil
    but not an event, the current maps will not be mouse-sensitive
    even when SEQUENCE is an event.

Re: A bug, I think, in key-binding

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> So I just checked all the calls to `key-binding' and `XYZ-key-binding'
> in the Emacs sources (except those in viper).  It seems that this
> change would hardly ever cause a bug, and often might fix a bug.  So I
> am now in favor of your proposal.
>
> Would someone please implement this, then ack this message?

Well, I'll try my hand at it tomorrow (I'm gone for the evening), and
I'll report back on whether I actually manage: I have pretty little
experience with Emacs-C.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum