Re: Enhancements to "minor-mode-map-alist" functionality.

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> 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 <address@hidden> http://www.cua.dk