[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: |
22 Apr 2002 17:15:59 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 |
"Stefan Monnier" <monnier+gnu/address@hidden> writes:
> > "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.
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 <address@hidden> http://www.cua.dk
- Re: Enhancements to "minor-mode-map-alist" functionality., (continued)
- Message not available
- Message not available
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/14
- 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 <=
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 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., Richard Stallman, 2002/04/20
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/21
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/04/22
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/22
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/04/22
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/23
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/04/22
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/04/23