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

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

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > 
> > > > "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> 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.

Oh, sorry I don't know why I said that....

Of course there is some overlap between some of those keymaps.
E.g. C-x is bound in various ways in three of the keymaps, and
`kill-ring-save' is remapped differently in three other keymaps.

See the completely list of bindings (with overlap) at the end of this
message.

> 
> > > 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))

Yes, I can see the potential.

AFAICS, the overlap can be handled by something like this:

        (defun cua-krs-filter (b) 
           (cond 
             (cua-global-mark-active 'cua-kill-to-global-mark)
             (cua-rectangle 'cua-kill-rectangle)
             (mark-active  'cua-kill-region)
             (t nil)))    
        (define-key cua-mode-map [remap kill-ring-save]
 	  '(menu-item "-" nil :filter cua-krs-filter))

But that would not be practical for cua (too much overlap).

> 
> > > 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.
> 

Exactly.

> 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).

I stand corrected.

Again, I'm sorry about the misinformation re. overlap.
But I still fail to see how this approach can address all 
the requirements for cua.

Here is the complete list of keymaps and bindings used by
cua in its current state:

				1 - cua--prefix-override-keymap
				.   2 - cua--prefix-repeat-keymap
				.   .  	3 - cua--cua-keys-keymap
				.   .  	.   4 - cua--global-mark-keymap
				.   .  	.   .	5 - cua--rectangle-keymap
				.   .  	.   .	.   6 - cua--region-keymap
Key binding			.   .  	.   .	.   .	7 - cua--global-keymap
(* indicates remap)		.   .  	.   .	.   .   .
-----------------------------------------------------------------------------
C-x				1  (2) (3)
C-c				1  (2) (3)
C-x C-x			       (1)  2
C-x up	    		       (1)  2
C-x down    		       (1)  2
C-x left    		       (1)  2
C-x right   		       (1)  2
C-x timeout		       (1)	3
S-C-x					3
C-c C-c			       (1)  2
C-c up	    		       (1)  2
C-c down    		       (1)  2
C-c left    		       (1)  2
C-c right   		       (1)  2
C-c timeout		       (1)	3
S-C-c					3
C-z					3
C-v					3
RET					    4	5
TAB						5
S-return					5   6	7
H-space						5   6	7
mouse-1						5
down-mouse-1					5
drag-mouse-1					5
mouse-3						5
down-mouse-3					5
drag-mouse-3					5
H-mouse-1						7
S-C-SPC							7
C-?						5
M-up						5
M-down						5
M-left						5
M-right						5
C-M-up						5
C-M-down					5
M-a						5
M-b						5
M-c						5
M-f						5
M-F						5
M-i						5
M-k						5
M-l						5
M-m						5
M-n						5
M-o						5
M-p						5
M-P						5
M-r						5
M-R						5
M-s						5
M-t						5
M-u						5
M-|						5
M-'						5
M-/						5

*exchange-point-and-mark		3
*yank					    4		7
*clipboard-yank						7
*yank-pop						7
*set-mark-command				5	7
*undo							7
*advertised-undo					7
*self-insert-command			    4	5   6
*self-insert-iso			    4	5   6
*insert-register				    6
*newline-and-indent			    4	    6
*newline				    4	    6
*open-line					    6
*delete-backward-char			    4	5   6
*backward-delete-char			    4	5   6
*backward-delete-char-untabify		    4	5   6
*delete-char				    4	5   6
*kill-region				    4	5   6
*copy-region-as-kill			    4	5   6
*kill-ring-save				    4	5   6
*keyboard-escape-quit			    4	    6
*keyboard-quit				    4	    6
*forward-char					5
*backward-char					5
*next-line					5
*previous-line					5
*end-of-line					5
*beginning-of-line				5
*end-of-buffer					5
*beginning-of-buffer				5
*scroll-down					5
*scroll-up					5


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