Valdis.Kletnieks(a)vt.edu writes:
> 1) You don't know what their keyboard looks like (and we probably
> can't do the sort of things Apple did with the Macintosh 'Key Caps'
> program).
This is probably irrelevant, given that we can and should use Emacs
keystroke abstractions like "M-foo" or "C-bar". Even if we did know
what their keyboard looked like, it would be worth shit on TTY's.
Emacs key sequences at least have a well-defined meaning everywhere.
> 2) A user trying to customize keymaps may not *know* or *care*
> what the underlying Lisp function is called.
There's not much Customize can do about this, nor about your third
point. I was actually talking about a totally different (and more
earthly, dare I say) range of problems.
The situation I'd like Customize to deal with is a way to say
`M-x customize-keymap RET c-mode-map RET', and handling this sensibly.
My first attempts were to convert the keymap into an alist, and
present the user with editing the alist in a Customize-like
environment, but that sucked, for three reasons:
1) The a-list was extremely large and cumbersome to edit. This is a
general problem with Customize, which cannot (easily) *modify*
complex data structures.
2) There were problems with conversions of a-list keys (if you'll
excuse the pun) to the canonical format. For example, all of C-i,
C-I, and TAB can be assigned to different things in XEmacs, with
a list of "inheritance". These things are not easy to represent in
a UI.
3) It is hard for such view to represent all the more complex things
that keymaps can do, such as setting parents or certain flags. A
similar problem exists with editing faces via Customize.
