From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Assignment of misc packages for emacs Date: 08 Jun 2002 13:06:16 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: <87sn3ypg7b.fsf@tc-1-100.kawasaki.gol.ne.jp> 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> <200206061204.g56C4qf24692@aztec.santafe.edu> <87r8jka8bm.fsf@tc-1-100.kawasaki.gol.ne.jp> <200206072323.g57NNXU27361@aztec.santafe.edu> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1023509382 11448 127.0.0.1 (8 Jun 2002 04:09:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 8 Jun 2002 04:09:42 +0000 (UTC) Cc: monnier+gnu/emacs@RUM.cs.yale.edu, storm@cua.dk, 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 17GXXq-0002yX-00 for ; Sat, 08 Jun 2002 06:09:42 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17GXtW-0006bG-00 for ; Sat, 08 Jun 2002 06:32:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17GXXF-0000iu-00; Sat, 08 Jun 2002 00:09:05 -0400 Original-Received: from smtp02.fields.gol.com ([203.216.5.132]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17GXVL-0000Wb-00; Sat, 08 Jun 2002 00:07:08 -0400 Original-Received: from tc-2-210.kawasaki.gol.ne.jp ([203.216.25.210] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp02.fields.gol.com with esmtp (Magnetic Fields) id 17GXVJ-0001nH-00; Sat, 08 Jun 2002 13:07:05 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id 2FE8B30A4; Sat, 8 Jun 2002 13:06:17 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu In-Reply-To: <200206072323.g57NNXU27361@aztec.santafe.edu> Original-Lines: 50 X-Abuse-Complaints: abuse@gol.com Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4646 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4646 Richard Stallman writes: > The code to understand the menu items has to be somewhere; I don't see > any reason why it should not be in Lisp. After all, there is Lisp > code to create menu items. > > Meanwhile, this creates another ad-hoc representation for the same > data. Ok, sounds good to me [I mean, passing a raw keymap to the lisp code]. After looking at the C code more closely, I'm a bit confused about what's actually happening (my patch just retained the original code for scanning the keymaps, so I didn't write it). It seems to use _multiple_ keymaps (the MAPS and NMAPS parameters), which it merges to get all the menu entries. Can any explain in what situation you end up with multiple keymaps that need to be merged like this? Should the lisp function be passed a list of keymaps? It would also be nice to have some helper functions/forms to assist lisp code in manipulating the keymaps without caring too much about the details. For this current application, for instance, I'd like: 1) something to iterate over the keymaps E.g. perhaps (dobindings (VAR KEYMAP [PREDICATE]) BODY..) 2) accessor functions of some sort for the tricky bits For menu-items, as I mentioned earlier, there's already this handy C function `parse_menu_item' which could be used to do the bulk of the work for any accessor function(s). I'm not sure what would be better though, a bunch of individual accessor functions, e.g., (menu-item-help MENU-ITEM), or one big accessor function like (menu-item-property MENU-ITEM :help). The second would probably be easier to implement, since parse_menu_item fills in a table, so a general accessor funciton like `menu-item-property' could just have a list of keyword->table-index mappings. What are people's opinions about the best way to do these things? [Stefan...?] -Miles -- Quidquid latine dictum sit, altum viditur.