From: David Kastrup <dak@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: A bug, I think, in key-binding
Date: Fri, 18 Aug 2006 13:02:03 +0200 [thread overview]
Message-ID: <85oduitihg.fsf@lola.goethe.zz> (raw)
In-Reply-To: <E1GDaxo-0000wm-Jv@fencepost.gnu.org> (Richard Stallman's message of "Thu, 17 Aug 2006 02:02:44 -0400")
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
next prev parent reply other threads:[~2006-08-18 11:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-08 22:47 A bug, I think, in key-binding David Kastrup
2006-08-09 4:58 ` Richard Stallman
2006-08-09 5:18 ` Stefan Monnier
2006-08-10 1:13 ` Richard Stallman
2006-08-17 6:02 ` Richard Stallman
2006-08-17 14:48 ` Stefan Monnier
2006-08-18 15:47 ` Richard Stallman
2006-08-18 11:02 ` David Kastrup [this message]
2006-08-22 15:41 ` Richard Stallman
2006-08-22 16:39 ` David Kastrup
2006-08-09 7:03 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85oduitihg.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.