catching keyboard-quit from read-char

catching keyboard-quit from read-char

[Eric Abrahamsen]

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

I thought this used to work, but maybe I'm mis-remembering. Is there
anything I can do to get this to behave the way I want it to? (Ie,
returning nil).

Thanks,
Eric

Re: catching keyboard-quit from read-char

[Eric Abrahamsen]

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

Re: catching keyboard-quit from read-char

[Noam Postavsky]

On 26 July 2018 at 16:03, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:

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

Why not use register-read-with-preview (uses read-key), which seems
like the function specifically made for this?

Other possibilities are read-multiple-choice (currently uses
read-char, but maybe should be changed to read-event, see Bug#32257),
read-answer (uses read-from-minibuffer + keymap) which is new in
master, but I plan to backport to emacs-26 soon (see Bug#31782).

Re: catching keyboard-quit from read-char

[Eric Abrahamsen]

Noam Postavsky <npostavs@gmail.com> writes:

> On 26 July 2018 at 16:03, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
>> 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.
>
> Why not use register-read-with-preview (uses read-key), which seems
> like the function specifically made for this?

Dunno what I was thinking there -- I'd even looked at the code of that
function to see how it worked, yet somehow it didn't occur to me to just
use it. Thanks for the nudge.

> Other possibilities are read-multiple-choice (currently uses
> read-char, but maybe should be changed to read-event, see Bug#32257),
> read-answer (uses read-from-minibuffer + keymap) which is new in
> master, but I plan to backport to emacs-26 soon (see Bug#31782).

Thanks for this -- I hadn't seen read-answer yet. A bit of scratch
buffer experimentation makes it look like they behave almost exactly the
same way -- why do we have two?

One other function I wish Emacs had (which I think many of us have ended
up writing ourselves) is `choose-thing-from-list'. The existing
functions return strings or characters; I'd love a function that
accepted a list of things, and a function used to derive
string/character keys for the things, and then returned the thing
itself, not the key.

But I'm off topic at this point...

Thanks again,
Eric

Re: catching keyboard-quit from read-char

[Noam Postavsky]

On 27 July 2018 at 13:15, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:

>> Other possibilities are read-multiple-choice (currently uses
>> read-char, but maybe should be changed to read-event, see Bug#32257),
>> read-answer (uses read-from-minibuffer + keymap) which is new in
>> master, but I plan to backport to emacs-26 soon (see Bug#31782).
>
> Thanks for this -- I hadn't seen read-answer yet. A bit of scratch
> buffer experimentation makes it look like they behave almost exactly the
> same way -- why do we have two?

read-answer can take both single character and full string input
depending on user preference.