bug#73584: 29.3; read-key

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 2 Oct 2024 10:02:44 +0000
> Cc: 73584@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Tue, 01 Oct 2024 13:21:11 -0500
> >> From: Devon Sean McCullough <Emacs-hacker2023@jovi.net>
> >>
> >> (read-key 0) jails Emacs in a null keymap.
> >
> > You should be able to escape the jail with ESC or C-[.
> >
> > I don't see a bug here.
> 
> It would arguably be a bit nicer to signal the error early to avoid
> having to mash C-[:

Maybe.  But what exactly is wrong with signaling the error from
read-key-sequence-vector, which read-key calls?

> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -3307,6 +3307,8 @@ read-key
>  what you want as `read-key' temporarily removes all bindings
>  while calling `read-key-sequence'.  If nil or unspecified, the
>  only unbound fallback disabled is downcasing of the last event."
> +  (or (stringp prompt)
> +      (signal 'wrong-type-argument (list 'stringp prompt)))

This will signal an error if PROMPT is nil or omitted, which we
definitely must support.

>    ;; This overriding-terminal-local-map binding also happens to
>    ;; disable quail's input methods, so although read-key-sequence
>    ;; always inherits the input method, in practice read-key does not
> 
> BTW, do we have something like `cl-check-type' outside of cl-lib?

We shouldn't use any cl stuff in subr.el, surely?