GNU bug report logs - #73584
29.3; read-key

Previous Next

Package: emacs;

Reported by: Devon Sean McCullough <Emacs-hacker2023 <at> jovi.net>

Date: Tue, 1 Oct 2024 18:22:02 UTC

Severity: normal

Found in version 29.3

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73584 <at> debbugs.gnu.org, Emacs-hacker2023 <at> jovi.net
Subject: bug#73584: 29.3; read-key
Date: Wed, 2 Oct 2024 21:47:19 +0000
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Wed, 2 Oct 2024 10:02:44 +0000
>> Cc: 73584 <at> debbugs.gnu.org
>>
>> 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?

I just observe that I have to mash C-[ to get back control of Emacs, and
that it would probably have been better if I didn't have to.  I imagine
situations when this happens because of a bug in some library, and users
won't know what to do in that situation.  It clearly confused OP.

>> --- 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.

Thanks, yes.  That would have to be amended.

>>    ;; 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?

I meant to ask if we have something similar to `cl-check-type' that does
not come from cl-lib.el.  I'm asking that precisely because we can't use
cl-lib in subr.el.

It would have been convenient if we had something like:

    (defmacro check-type (form predicate)
       `(unless (,predicate form)
           (signal 'wrong-type-argument (list ,predicate form))))

We have this pattern in quite a few places in our code, so maybe we
should consider adding it if we don't have it already.




This bug report was last modified 206 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.