Re: catching keyboard-quit from read-char

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I thought this used to work, but maybe I'm imagining things...
>
> I've got a macro for prompting the user for a value, but catching a
> couple of signals and returning nil in those cases. It looks like:
>
> (defmacro ebdb-with-exit (&rest body)
>   "Execute BODY, returning nil on quit or an empty value."
>   `(condition-case-unless-debug nil
>        ,@body
>      ((quit ebdb-empty)
>       nil)))
>
> It works for `read-string', but not `read-char':
>
> (ebdb-with-exit (read-string "String: ")) ; C-g returns nil
> (ebdb-with-exit (read-char "Character: ")) ; C-g raises an error

Hmm, I guess `read-char' is a function on a different order than
`read-string': the former belongs to the family of event readers, the
latter to the family of minibuffer readers. Though I still don't quite
understand why keyboard-quit is raised in an uncatchable fashion: it
seems like either it should be raised and catchable, or else returned as
a literal "C-g" key event.

Interestingly, `read-char-choice' is not part of minibuffer.el, but it
seems to duplicate a lot of the minibuffer work (propertizing the
prompt, catching "C-g" as an key event and raising (keyboard-quit),
etc).

My use case above is prompting for a character to use as a register
name. I guess I can just use `read-char-choice', offering as choices all
the valid register keys from `register-alist'. The only downside is that
if the user enters an invalid character nothing happens: there's no
message indicating that they've entered an invalid character, it just
sits and waits for valid input.

Anyway, this was an interesting foray into event reading.

Eric