From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: What happened to the key-menu patch? Date: Tue, 09 Jul 2002 09:58:47 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200207091358.g69Dwlr26999@rum.cs.yale.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> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1026223525 18887 127.0.0.1 (9 Jul 2002 14:05:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Jul 2002 14:05:25 +0000 (UTC) Cc: storm@cua.dk (Kim F. Storm), rms@gnu.org, 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 17RvcL-0004uW-00 for ; Tue, 09 Jul 2002 16:05:25 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Rvkn-00055p-00 for ; Tue, 09 Jul 2002 16:14:09 +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 17RvWX-0006BU-00; Tue, 09 Jul 2002 09:59:25 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17RvW2-00067G-00; Tue, 09 Jul 2002 09:58:54 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g69Dwlr26999; Tue, 9 Jul 2002 09:58:47 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Miles Bader 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:5599 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5599 > I guess we should add a `map-keymap' for xemacs compatibility. I don't think it's just for compatibility but also because it makes sense. > sure if it's worth it to add a `dobindings' macro or not. Agreed. There's already a `loop' macro for it in CL. > key-description list' is, but it's something like (meta control x). > I guess this is a canonical format for key names in xemacs, but it > doesn't appear to be so in emacs, so I'm not sure how that argument > should be handled (perhaps just punt, and pass whatever's stored in > the keymap). I don't think we should try to re-create the XEmacs (meta control x) form from our M-C-x symbols. We could provide an additional compatibility layer on top of it, if it proves useful/necessary later on. > (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). We could just pass the > whole menu entry (e.g., (menu-item ...)) as the first argument, and > perhaps extract the binding and pass it as the second arg, or even > pass something else for that. XEmacs' keymap do not contain menu entries (of toolbar entries for that matter). As for how we should treat them, I think we should not do anything special with them: i.e. `function' will be called with key `menu-bar' and with the corresponding sub-keymap as the binding. > affect the usual case (unless you're Stephan). ^^ f (couldn't resist) I have appended my current code. It has several shortcomings, especially the ugly "use integers to specify hard-coded C functions". Also there is the issue of eliminating/merging duplicate bindings, which I think XEmacs' code punts on by declaring that `map-keymap' does not look at the keymap's parent(s). As you can see, the code is tentative and not ready for prime-time. I only show it to give an idea of what I'm thinking of. Stefan extern void menu_bar_item P_ ((Lisp_Object, Lisp_Object, Lisp_Object)); static void (*map_keymap_functions[]) P_ ((Lisp_Object, Lisp_Object, Lisp_Object)) = { menu_bar_item }; static void map_keymap_item (closure, key, val) Lisp_Object closure, key, val; { Lisp_Object fun = XCAR (closure); Lisp_Object args = XCDR (closure); if (EQ (val, Qt)) val = Qnil; if (NATNUMP (fun)) map_keymap_functions[XFASTINT (fun)](args, key, val); else call3 (fun, args, key, val); } static void map_keymap_char_table_item (closure, key, val) Lisp_Object closure, key, val; { if (!NILP (val)) map_keymap_item (closure, key, val); } /* Call CLOSURE for every binding in MAP. CLOSURE is a cons cell of the form (FUN . ARGS). FUN is called with three arguments: FUN (ARGS, KEY, BINDING). If FUN is an integer, it denotes the index of the function to use from `map_keymap_functions'. */ void map_keymap (closure, map, autoload) Lisp_Object map, closure; int autoload; { struct gcpro gcpro1, gcpro2, gcpro3; Lisp_Object tail; GCPRO3 (map, closure, tail); map = get_keymap (map, 1, autoload); for (tail = (CONSP (map) && EQ (Qkeymap, XCAR (map))) ? XCDR (map) : map; CONSP (tail) || (tail = get_keymap (tail, 0, autoload), CONSP (tail)); tail = XCDR (tail)) { Lisp_Object binding = XCAR (tail); if (CONSP (binding)) map_keymap_item (closure, XCAR (binding), XCDR (binding)); else if (VECTORP (binding)) { /* Loop over the char values represented in the vector. */ int len = ASIZE (binding); int c; abort(); for (c = 0; c < len; c++) { Lisp_Object character; XSETFASTINT (character, c); map_keymap_item (closure, character, AREF (binding, c)); } } else if (CHAR_TABLE_P (binding)) { Lisp_Object indices[3]; map_char_table (map_keymap_char_table_item, Qnil, binding, closure, 0, indices); } } UNGCPRO; }