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

[storm@cua.dk (Kim F. Storm)]

Richard Stallman <rms@gnu.org> writes:

>        SUBMAPS is a list of keymaps which are used at the same
>        level as the bindings of this keyamp, but comes before those
>        bindings.
> 
> What does that mean?

Consider a keymap K which has a binding for [C-x 1],
a keymap P which has a binding for [C-x 2], and
a keymap S which has a binding for [C-x 3].

Keymap S has a filter which means that it is only active
if mark-active is non-nil.

Now, we want keymap P to be a parent map for K, and
we want S to be a submap of K.

With my proposal, C-x 1, C-x 2, and (if mark-active) C-x 3 will all
work seemlessly *without* having to rely on fix_submap_inheritance
(which only works for one submap [the parent map] anyway).


> What problem is it meant to solve?

Multiple keymap inheritance as well as conditional keymaps.

> 
>     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.
> 
> There is no way to implement such a restriction,
> and users don't generally know which functions do consing.

This is not intended to be a user feature, it is for package
writers. 

I didn't think we should `implement' the restriction -- simply
document it.  It could be a fairly short list of
`safe' functions to apply to variables, e.g. 
and, or, not, if, eq, equal, quote,
member, memq, get, assoc, car, cdr, aref, 
=, /=, >, >=, <, <=,
symbolp, numberp, vectorp, timerp, (etc)
boundp, fboundp, featurep, (etc)

I believe this would cover all practical purposes, so I don't see why
we need to make a significantly more complex solution to handle some
theoritical cases.

> 
> What we should do is make this code work correctly.
> 

If you still think this is what you think is necessary,
one solution could be:

- memory_full set a global variable 'out-of-memory'.

- the command loop will (somehow) determine whether
  the out-of-memory condition is no longer present
  e.g.
        if (out_of_memory)
          {
            void *tem = malloc(100000);
            if (tem)
              {
                out_of_memory = 0;
                free(tem);
              }
          }

- if out_of_memory is set, the current_maps function will not evaluate
  the keymap filters, but just assume they evaluate to the most recent
  result of evaluting the filter.


*) I proposed to use a vector [FILTER SUBMAPS PARENT] for the keymap
properties.  This could easily be extended to store the result of the
most recent evaluation of the FILTER, e.g.
        [FILTER FRES SUBMAPS PARENT]

where current_maps would store the result of eval'ing FILTER in
FRES.

Maybe not a perfect solution, but I believe it would work well enough
for this particular purpose (after all, running out of memory
fortunately isn't something we experience every day [anymore]).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk