From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: What happened to the key-menu patch? Date: Tue, 9 Jul 2002 12:51:21 -0600 (MDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200207091851.g69IpLf13841@aztec.santafe.edu> References: <200205050534.g455YfF01634@aztec.santafe.edu> <5xbsbumexh.fsf@kfs2.cua.dk> <200205141941.g4EJfud15293@aztec.santafe.edu> <5xvg9qmgzt.fsf@kfs2.cua.dk> <200205151927.g4FJRRW26103@rum.cs.yale.edu> <5x3cwr4q7m.fsf@kfs2.cua.dk> <87g00rd74y.fsf@tc-1-100.kawasaki.gol.ne.jp> <87sn4otknt.fsf@tc-1-100.kawasaki.gol.ne.jp> <200205191441.g4JEfMg23080@rum.cs.yale.edu> <200205202134.g4KLYHj26031@aztec.santafe.edu> <200205222227.g4MMRIX29393@aztec.santafe.edu> <87g0030xah.fsf@tc-1-100.kawasaki.gol.ne.jp> <5xn0t3p362.fsf_-_@kfs2.cua.dk> Reply-To: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1026240707 31403 127.0.0.1 (9 Jul 2002 18:51:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Jul 2002 18:51:47 +0000 (UTC) Cc: storm@cua.dk, monnier+gnu/emacs@RUM.cs.yale.edu, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17S05T-0008AO-00 for ; Tue, 09 Jul 2002 20:51:47 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17S0E1-0003Bp-00 for ; Tue, 09 Jul 2002 21:00:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17S05z-0002Dm-00; Tue, 09 Jul 2002 14:52:19 -0400 Original-Received: from pele.santafe.edu ([192.12.12.119]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17S055-00024y-00; Tue, 09 Jul 2002 14:51:23 -0400 Original-Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.11.6+Sun/8.11.6) with ESMTP id g69IpMB21859; Tue, 9 Jul 2002 12:51:22 -0600 (MDT) Original-Received: (from rms@localhost) by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g69IpLf13841; Tue, 9 Jul 2002 12:51:21 -0600 (MDT) X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f Original-To: miles@gnu.org In-Reply-To: (message from Miles Bader on 09 Jul 2002 16:00:13 +0900) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5604 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5604 I guess we should add a `map-keymap' for xemacs compatibility; I'm not sure if it's worth it to add a `dobindings' macro or not. Ok, let's make it map-keymap. (1) The xemacs manual doesn't seem to explain very well what `a key-description list' is, but it's something like (meta control x). In Emacs this should be an event type. (2) How are menu entries handled with this? I'm not sure whether xemacs even stores menus in keymaps or not (it's somewhat hard to tell, since keyaps are an opaque type in xemacs, and just calling map-keymap doesn't yield anything obvious). In XEmacs, menus are completely separate from keymaps. (I think that is a serious design error.) We can handle menu items just like all other keymap entries. Each menu item is installed as the definition of some event type. Following the usual specificiations, it should pass the the event type as the first argument and the whole key binding value as the second argument. Everything should just work, if you write the function properly. It may not be necessary to do anything special for menu bindings, or perhaps it is necessary to strip off the cached shortcut info. map-keymap should have an optional argument saying to ignore menu bindings. I think map-keymap should have another optional argument which controls whether to scan the parent keymaps. Let's choose the default for this for compatibility with XEmacs, and make a non-nil argument specify the other choice.