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

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/address@hidden> writes:
> 
> > > "Stefan Monnier" <monnier+gnu/address@hidden> writes:
> > > > I haven't heard any comment about my proposal to use `menu-item'
> > > > bindings with a :enable setting in order to get conditional bindings
> > > > (this doesn't currently work, but it should be pretty easy to make
> > > > it work).
> > > > Would it help you solve your problems ?
> > > 
> > > Considering that cua has approx 100 bindings in 7 keymaps,
> > > it seems like absolute overkill IMO to condition each of those
> > > 100 bindings individually instead of just the 7 keymaps which
> > > contain those bindings...
> > 
> > Is that 7*100 bindings or 7*14 bindings ?
> 
> It is 8 + 7 + 2 + 10 + 17 + 60 + 16 bindings...

So, more like 7*14.
How many of those bindings are in submaps (rather in the toplevel maps)
such that the :enable condition could be put on the prefix and thus shared ?

> > How much overlap ?
> None.

You mean that C-x is only bound in one of those 7 keymaps ?
But if there's no overlap, then the order of those maps relative
to each other is irrelevant.

> > How many different conditions would there be ?
> There are 7 different conditions.

If there's really no overlap and thus only 7 conditions, then the only
difference between my proposal and yours is that in my proposition
the condition is put on each binding inside the toplevel map rather
than being "outside the toplevel".

So the situation is very much like the use of :filter.  Actually
we could use :filter to get the :enable behavior without any change
to the C code at all.  I.e. if a binding was made like

        (define-key cua-foo-map key bind)

and assuming that the conditional corresponding to cua-foo-map is
cua-foo-predicate, the new code would simply do:

        (defun cua-foo-filter (b) (if (eval cua-foo-predicate) b))
        (define-key cua-mode-map key
          '(menu-item "bla" bind :filter cua-foo-filter))

> > For the sake of describe-key, I think it's better to have fewer bindings
> > (with the dispatch done more often in the bound function rather
> > than in the :enable conditionals) so that the docstring can describe what
> > happens when.
> 
> I don't think you will see any difference whether this is done
> via conditions in the minor-mode-map-alist (or emulation-mode-map-alist),
> or by conditioning each command individually.

I was assuming that there would be overlap between the maps such that
C-x is bound in several of your maps, so that C-h k would point you
to a different function/docstring depending on the circumstance.
Whereas if the conditional is tested inside the C code, then C-h k
gets you to the function that can then conveniently describe the
difference circumstances and their effect.

Of course, if there's no overlap, there's indeed no difference.

> Also, I don't see why it is better to eval the various conditions 100 times
> rather than just 7 times?

I don't see why the condition should be evaluated more times with my
proposal than with yours.  Actually, in your proposal, 7 conditions
are being evaluated for each command (they're evaluated right at the
beginning, in order to know which keymaps to look up), whereas in
mine only between 1 and 7 conditions would be evaluated (if there's
no overlap between the 7 maps, only 1, but if the current key pressed
is present in all 7 of your maps, then 7).


        Stefan