John H Palmieri <John.H.Palmieri.2(a)nd.edu> writes:
Hrvoje Niksic <hniksic(a)srce.hr> writes:
> I guess `princ' could be changed to `prin1' without too many
> problems, but binding keys to anonymous functions and then
> complaining about `C-h k' output is ridiculous.
You might even say that binding keys to anonymous functions is
ridiculous,
I was very careful not to say that because it wouldn't be true.
Although not stylistically "nice", binding keys to anonymous functions
is very convenient and perfectly legal. But when you do that, you
really shouldn't expect that part of `C-h k' output to be nice.
but if someone does it in some lisp code, and some else tries to get
help on the key, they should get helpful help. If using `prin1'
will make the help message better, why not change it?
No reason not to -- if you want to do it, I believe the patch will be
accepted. It's just that I don't see it as a bug that would require
our attention, if it can be considered a bug at all.
(Certainly, once I find out about that variable, I'll have some
idea
what it is. I tend to rely on the info files for documentation, so
if the variable isn't mentioned in those, I'm not likely to find it.
My second option is to browse through Emacs lisp files. I haven't
done anything approaching a thorough search, but I haven't found the
variable in any of those, either. I guess I'll have to start
reading the c source code, like you said...8-|)
If it makes you feel better, I believe I stumbled upon the variable
accidentally.
> Whether the resulting behaviour in your case is correct is
another
> question. I think it is.
I'm not sure what you mean by "correct". As far as I can tell, the
behavior I see agrees with the documentation, so it is "correct".
Accordance with the documentation is only one measure of correctness.
There are others, such as Emacs 18 compatibility (very strong in
keymap.c and event-stream.c), FSF Emacs compatibility,
"intuitiveness", etc.
(Only as far as I can tell, though: does some info file actually say
what happens in a keymap if shifted keys are undefined?)
I don't know. A perfunctory search yielded no matches, which might
mean the feature is undocumented, along with the
`retry-undefined-key-binding-unshifted' variable.
On the other hand, I think it would be better if one could actually
define keymaps in which "a" does something and "A" does not. (For
example, one might want to do this in dired mode. For another
example, when typing TeX documents, one might want a keymap for
typing Greek letters and other symbols, so hitting `g will insert
"\gamma", `G will insert "\Gamma", `a will insert "\alpha",
and `A
will beep, because there is no "\Alpha" in TeX.
But you can do that. Just bind "A" to a function that will signal
error. Or bind it to `keyboard-quit'.
The behavior now may be correct, but that doesn't mean it
can't be
improved. (I can think of several options: for example, defining a
key to be 'undefined could override the value of
retry-undefined-key-binding-unshifted, or the value of this variable
could be "local" to each keymap.
Yes, that would be useful indeed. Like a "keymap property". Except
that it's non-trivial to do, because keymaps actually hold subkeymaps,
and the property should be propagated correctly.