drew.adams@oracle.com: bug in read-kbd-macro

[Richard Stallman <rms@gnu.org>]

Would someone please DTRT and ack?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-pretest-bug@gnu.org>
Date: Sun, 24 Sep 2006 00:47:27 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
In-Reply-To: <EIENLHALHGIMHGDOLMIMIEIPCLAA.drew.adams@oracle.com>
Subject: RE: single-key-description no good for Japanese and Chinese chars
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

I ran across this issue/question. I don't know know if it is a bug or not.
If not, perhaps someone has a suggestion of how to deal with it.

I have strings that name keys in keymaps (from map-keymap). Some are prefix
keys. Examples: "C-x", "modeline", "f1".

I use `read-kbd-macro' with the string name as first arg and t as the
second, NEED-VECTOR arg. Example: "C-x" gives [24].

If the binding of the key is a keymap, so the key is a prefix key, then I
concatenate the current prefix-key name (e.g. [] for global) with the key
name: (vconcat prefix key). Example, when using map-keymap over the
global-map, the prefix is [] and, for key [24] this gives [24].

This works fine for prefix keys that are not names, but it does not work for
named prefix keys, such as `mode-line' and `f1'. The reason is that
(read-kbd-macro "mode-line" t) does not return [mode-line]; it returns the
equivalent of "mode-line", that is, a vector of characters: [109 111 100 101
45 108 105 110 101].

When I try to look up accessible-keymaps of that prefix, I obviously get
none. That is, whereas (accessible-keymaps (current-global-map) [mode-line])
would work, the call generated is instead (accessible-keymaps
(current-global-map) "mode-line"), or, more exactly, (accessible-keymaps
(current-global-map) [109 111 100 101 45 108 105 110 101]), which fails.

The first question is whether this is a bug: should (read-kbd-macro
"mode-line" t) return [mode-line]?

If not, I guess I'll need some other way to convert names to vector keys for
the prefix keys. Suggestions? If I knew that a given prefix-key name was a
"named" prefix key (as opposed to a control key name, for instance), then
instead of using `read-kbd-macro' I would use just (vector (intern key)).
That is, I'd use `read-kbd-macro' for "C-x" but (vector (intern
"mode-line")). Anyone know how to make such a distinction?

To complicate things, I see that (read-kbd-macro "<mode-line>"), with or
without the second arg, returns [mode-line]. However, I use key names
without angle brackets (because they are much more readable), and, again, I
don't know how to distinguish the named keys, to add back the angle brackets
internally, just for `read-kbd-macro'.

I thought also of trying to use `kbd' on the key name, hoping that might
help, but (kbd "mode-line") also gives "mode-line". I wonder too if that
might be a bug.

Yes, if I use angle-bracketed key names (strings), then the problem does not
arise, but I really don't want to do that, as it is a zillion times less
readable. Here is a sample of the *Completions* buffer in each style, to
show what I mean:

Without angle brackets:

C-M-S-backspace  =  copy-to-register
C-M-S-delete  =  append-to-register
C-M-S-f1  =  rename-buffer         C-M-S-insert  =  insert-file
C-M-backspace  =  backward-kill-sexp
C-M-delete  =  kill-sexp           C-M-down  =  enlarge-frame
C-M-down-mouse-1  =  mouse-drag-secondary
C-M-drag-mouse-1  =  mouse-set-secondary
C-M-end  =  end-of-defun           C-M-f1  =  font-lock-fontify-buffer
C-M-home  =  beginning-of-defun    C-M-insert  =  lisp-complete-symbol
C-M-left  =  shrink-frame-horizontally

With angle brackets:

<C-M-S-backspace>  =  copy-to-register
<C-M-S-delete>  =  append-to-register
<C-M-S-f1>  =  rename-buffer       <C-M-S-insert>  =  insert-file
<C-M-backspace>  =  backward-kill-sexp
<C-M-delete>  =  kill-sexp         <C-M-down-mouse-1>  =
mouse-drag-secondary
<C-M-down>  =  enlarge-frame       <C-M-drag-mouse-1>  =
mouse-set-secondary
<C-M-end>  =  end-of-defun         <C-M-f1>  =  font-lock-fontify-buffer
<C-M-home>  =  beginning-of-defun  <C-M-insert>  =  lisp-complete-symbol
<C-M-left>  =  shrink-frame-horizontally

The effect is even worse when other keys that don't have angle brackets are
in the list. For example, C-d has no angle brackets, but <C-left> does.
Users don't think of these as being very different, but a simple sort of
*Completions* puts them very far apart. You can see from the snippets above
that the order is changed even among the same set of keys that take angle
brackets, because ">" is sorted after "-": `C-M-down' appears after
`C-M-down-mouse-1' when angle brackets are present.

Thx for any suggestions.

[BTW, the doc string of `read-kbd-macro' is a bit confusing, but the manual
is clear. The doc string names the args START &optional END, but it then
speaks of the possibility of a "single string argument" and a "second
argument NEED-VECTOR" for Lisp calls. This is correct, but it could perhaps
be worded better.]





_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------