emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug/feature - emacs doesn't tell you about keys with multiple prefi


From: Stefan Monnier
Subject: Re: bug/feature - emacs doesn't tell you about keys with multiple prefixes
Date: Sun, 16 Mar 2003 05:14:09 -0500

> With the code below, if you do "C-h k M-b M-a" , Emacs will tell you that
> mark-paragraph is on "M-h, M-a, M-b" ; it will not tell you that it is also on
> M-b M-a or M-b M-b (even though you just pressed those keys to get to this
> screen!). Same goes with the "matched:" message when you type M-x
> mark-paragraph (before you hit RET).
> 
> Regardless of bad coding style etc I it is useful to have aliases for prefixes
> - for example I like using M-v instead of/in addition to C-x v and the easiest
> way to do this is to (global-set-key [ (meta v) ] vc-prefix-map). This
> confusing behavior of displaying only keys under the first key bound to a
> keymap exists in Emacs 21 for the "M-x ... [matched; <keys>]" message and in
> Emacs CVS for describe-key as well.
> 
> 
> 
> (global-set-key [(meta a)] nil)
> (global-set-key [(meta b)] nil)
> 
> (global-set-key [(meta a) (meta a)] 'mark-paragraph)
> (global-set-key [(meta a) (meta b)] 'mark-paragraph)
> 
> ;;; >>>>>>>>>>>>>>>>>>>>>
> (global-set-key [(meta b)] (lookup-key (current-global-map) [(meta a)]))
> ;;; <<<<<<<<<<<<<<<<<<<<<
> 
> ;; after the previos line, these two lines have no effect on the reverse key 
> lookups.
> (global-set-key [(meta b) (meta a)] 'mark-paragraph)
> (global-set-key [(meta b) (meta b)] 'mark-paragraph)

It seems that it is done "on purpose".

In accessible-keymaps (used by where-is-internal), there is an explicit check
to remove any duplicate keymaps (i.e. the same keymap appearing under another
prefix).  Look for Frassq in accessible_keymaps_1 in keymap.c.

I'm not sure why it's there, but it's been there "for ever"
(i.e. since revision 1.1 of the file).  One benefit of removing duplicates
is that it prevents us from getting stuck in a cycle, although I'm not sure
how important this is.


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]