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.
