From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Enhancements to "minor-mode-map-alist" functionality. Date: 15 Apr 2002 00:32:34 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xu1qd29od.fsf@kfs2.cua.dk> References: <5xbscpg7zl.fsf@kfs2.cua.dk> <200204112243.g3BMhmI01190@rum.cs.yale.edu> <5xd6x5i7ps.fsf@kfs2.cua.dk> <5x4rih12b2.fsf@kfs2.cua.dk> <200204121846.g3CIkZY16909@rum.cs.yale.edu> <5xofgoobzr.fsf@kfs2.cua.dk> <200204122021.g3CKLh217680@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018820015 16952 127.0.0.1 (14 Apr 2002 21:33:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 14 Apr 2002 21:33:35 +0000 (UTC) Cc: 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 16wrct-0004PJ-00 for ; Sun, 14 Apr 2002 23:33:35 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16wruI-0000iI-00 for ; Sun, 14 Apr 2002 23:51:35 +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 16wrcc-0004PL-00; Sun, 14 Apr 2002 17:33:18 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16wrb7-0003mu-00 for ; Sun, 14 Apr 2002 17:31:45 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 1E8217C035; Sun, 14 Apr 2002 21:31:44 +0000 (GMT) Original-To: "Stefan Monnier" In-Reply-To: <200204122021.g3CKLh217680@rum.cs.yale.edu> Original-Lines: 92 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 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:2629 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2629 "Stefan Monnier" writes: > > > I like this idea so much that I have implemented it already, but > > > for the purpose of multiple inheritance and to get rid of the infamous > > > fix_submap_inheritance ugliness. It requires several non-trivial > > > changes, tho. And I haven't finished taking care of all the "problems" > > > it introduces (not all of them need to be addressed right away: for > > > example, it doesn't work for menus yet). > > > > Very good. When can I expect to see this in the tree (so I can use it?) > > I'd say "not very sooon". I can send you the code, if you want to try it out. > There are several issues as well as details about the implementation that > some developers might object to, so it's not clear that it would be accepted. > For example, access_keymap can now allocate cons cells to build the > return value (and often does). What about a very different approach: 1) We define a keymap as a list (keymap PROPS &rest bindings) where [PROPS] is an optional vector with 3 elements: [FILTER SUBMAPS PARENT] FILTER is a form which is eval'ed to determine whether this bindings in keymap should be used or ignored SUBMAPS is a list of keymaps which are used at the same level as the bindings of this keyamp, but comes before those bindings. PARENT is the parent keymap (or nil) which is the parent keymap if this keymap. 2) We modify current_minor_maps to return a array of active keymaps which includes _all_ the submaps and parent maps of any of the active keymaps. The keymaps are added in the proper order, (i.e. for each keymap first the submaps (and any submaps of those etc), then then map itself, and finally the parent map). If we do this, the existing keymap lookup functionality will take care of (among other things) multiple submap inheritance. [and it should NOT bother looking at the submaps or the parent maps, as they are included in the maps list. 3) I understand that there is a problem with evaling code which may do consing in current_minor_maps, but for most practical applications I would suppose that this isn't necessary. So maybe we can just restrict the FILTER forms/functions to not being allowed to do consing and document this restriction in the set-keymap-filter function. 4) If this is not acceptable [why not?], the interpretation of the FILTER functions must be done by the callers before actually using a keymap -- this is of course possible, but complicates the code (as we would then need to return the 'nesting level' of the keymaps in the returned maps array, so we can skip submaps of ignored maps). 5) It could be considered to rename current_minor_maps to current_maps and expand it to include the keymap and local-map property maps, the buffer local map, and the global map in the returned maps array. This would simplify the callers of current_minor_maps, and it would also allow the global map, buffer local maps, and property keymaps to have (conditioned) submaps and a parent keymap. I haven't had time to consider all the implications of this on the rest of the code, but besides the trivial changes needed to cope with the addition of the [PROPS] vector to keymaps, there are probably a few places where a little extra work is needed to get things to work smoothly. But maybe current_maps will use a helper function which can cope with expanding a single keymap into an array of submaps, and if necessary, other parts of the code can use this. Any interest in investigating these ideas further, or do you think it is a(nother) dead end? -- Kim F. Storm http://www.cua.dk