bug#35231: 26.1; Redefine `read-command' behavior for empty input and DEFAULT not a command name

[Lars Ingebrigtsen <larsi@gnus.org>]

Drew Adams <drew.adams@oracle.com> writes:

> This is a followup to bug #35222 (and thanks for fixing that doc bug).
>
> As discussed in #35222, the current C-code definition of `read-command'
> seems not so desirable, when it comes to DEFAULT = nil or "".
>
> The behavior in that case is to return an uninterned symbol whose name
> is empty, which has the read/print syntax `##'.
>
> This is _not_ a symbol whose function definition is `commandp'.  There
> is nothing about this symbol that qualifies for consideration as a
> command.  It seems wrong (a bug) for `read-command' to ever return a
> symbol whose function definition is `commandp'.

That is, indeed, pretty odd.  The function isn't used a lot in Emacs:

./lisp/subr.el1088:           (read-command (format "Set key %s to command: "
./lisp/edmacro.el118:	     (setq cmd (read-command "Name of keyboard macro to edit: "))
./lisp/emulation/edt.el1130:	(setq edt-function (read-command "Enter command name: "))
./lisp/info.el4526:	    (read-command "Find documentation for command: ")))
./lisp/strokes.el448:    (read-command "Command to map stroke to: ")))

But some of them expect this behaviour:

	     (setq cmd (read-command "Name of keyboard macro to edit: "))
	     (if (string-equal cmd "")
		 (error "No command name given"))

	(setq edt-function (read-command "Enter command name: "))
	(if (string-equal "" edt-function)
	    (message "Key not defined")

So changing the behaviour is probably not a good idea -- there may be
out-of-tree usages.  So I think we'll have to live with it, and I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no