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

[David Kastrup]

Richard Stallman <address@hidden> 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