bug#35222: 26.1; `read-command' documentation

[Drew Adams <drew.adams@oracle.com>]

> > 1. The doc string does not say what happens if DEFAULT is not provided
> >    (so `nil') and the user enters empty input.  And what happens is not
> >    obvious.  Please add that information to the doc string.
> 
> Um, can we declare the current behaviour a bug, and instead return nil
> in this case? That matches the current doc string (i.e., return
> DEFAULT-VALUE), and avoids the whole mess with the empty string symbol
> which is weird and pretty useless as far as I can tell.

Good question.  That was in fact my first reaction.
I wrote the bug report that way, then reconsidered.

I agree that the behavior is weird, and I'm not sure
what users, in what use cases, it could help.  IOW,
why?

But the behavior has apparently always been thus.

(Prior to Emacs 24 there was no such read/print
syntax for uninterned symbols, so it was arguably
even weirder.  If you used the result as a variable
value and did `C-h v' it would show you nothing!)

I ended up figuring that someone wanted this for
some good reason that I couldn't think of, and that
since it is documented this way (always returns a
symbol) and it is of long date we should just leave
it and make sure the doc string also helps.

But it sure is a gotcha.  Why the default DEFAULT
behavior would be something so unexpected is a
good question.  Hysterical accident?  Intentional
design?  Anyone know or have an idea what good this
is?

All I could think of is that code using it can be
sure to get a symbol.  But it sure isn't sure to
get a command...  I don't have the C sources, but
a priori (e.g. if I were writing `read-command'
from scratch in Lisp) it seems like it should
_require_ a commandp symbol, i.e., use
`completing-read' with non-nil REQUIRE arg.

Someone is sure to enlighten us.  When that happens,
and if the decision is to continue the behavior,
hopefully people will agree even more strongly with
the need to provide clear doc about this odd default
case.