[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enhancements to "minor-mode-map-alist" functionality.
From: |
Kim F. Storm |
Subject: |
Re: Enhancements to "minor-mode-map-alist" functionality. |
Date: |
15 Apr 2002 00:32:34 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 |
"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
- Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/11
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/04/11
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/12
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/12
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/04/12
- Message not available
- Message not available
- Re: Enhancements to "minor-mode-map-alist" functionality.,
Kim F. Storm <=
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/04/16
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/16
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/04/18
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/18
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/04/19
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/19
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/04/19
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/21
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/04/22
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/22