Well it seems quite obvious now that I simply overlooked the fact that quoting a list results in its elements not getting evaluated. I would argue that, although there might be no real bug in the doc, the doc still somehow helped me to overlook this fact. I think backquoting is not very much a hassle, but it would be nice to get reminded about it for when using the (kbd ...) construct. Of course if the (kbd "j") would not have worked I would have been less confused and maybe had found the mistake myself, but because that one did work it appeared to me to be a bug. Anyway, I think a simple change/addition in the docstring and/or the examples in section 23.3.3 of the elisp manual could help make things clearer.
> > The cons ((kbd "C-n") . 'foo) is exactly such a
> > (KEY . BINDING) pair - both KEY and BINDING are
> > suitable arguments for `define-key'.
>
> Is it?
>
> ELISP> (define-key global-map '(kbd "C-n") ''foo)
> *** Eval error *** Wrong type argument: arrayp, (kbd "C-n")
I get your point. I guess maybe there are two ways
to read the doc string.
The most _useful_ behavior for users, IMO, is for
`define-minor-mode' to allow expressions in arg
KEYMAP (when it's such a list) that correspond to
what a user writes in `(define-key ...)'.
Is that particular list form of KEYMAP intended
mostly for programmatically supplying such a list,
or for users to write such a list?
If the former, why is it needed/helpful at all,
since code can just as easily create a keymap arg.
If the latter, it gives users an easy way to write
key bindings directly for `define-minor-mode'.
I hadn't even paid attention to the existence of
such a form for the KEYMAP arg. But it looks like
it could be handy for users to write - IF the sexp
to write is simple and straightforward.
If users instead need to use backquote syntax or
jump through other hoops to write such a KEYMAP
sexp, then what's the point - what's the use case?
Maybe there _is_ a programmatic use case. If so,
what is it?