From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: A bug, I think, in key-binding Date: Fri, 18 Aug 2006 13:02:03 +0200 Message-ID: <85oduitihg.fsf@lola.goethe.zz> References: <858xly975r.fsf@lola.goethe.zz> <87y7tysd7e.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1155899748 26581 80.91.229.2 (18 Aug 2006 11:15:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 Aug 2006 11:15:48 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 18 13:15:46 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GE2K7-0003J0-B4 for ged-emacs-devel@m.gmane.org; Fri, 18 Aug 2006 13:15:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GE2K6-00023t-OU for ged-emacs-devel@m.gmane.org; Fri, 18 Aug 2006 07:15:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GE2Ju-00023o-8Q for emacs-devel@gnu.org; Fri, 18 Aug 2006 07:15:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GE2Jt-00023R-Ow for emacs-devel@gnu.org; Fri, 18 Aug 2006 07:15:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GE2Jt-00023K-Jv for emacs-devel@gnu.org; Fri, 18 Aug 2006 07:15:21 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GE2Qa-0008Tj-R9 for emacs-devel@gnu.org; Fri, 18 Aug 2006 07:22:16 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GE2Jl-0003Ku-Pf; Fri, 18 Aug 2006 07:15:14 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 030D41C4D3AF; Fri, 18 Aug 2006 13:02:03 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Thu, 17 Aug 2006 02:02:44 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58485 Archived-At: Richard Stallman 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