* catching keyboard-quit from read-char
@ 2018-07-25 22:11 Eric Abrahamsen
2018-07-26 20:03 ` Eric Abrahamsen
0 siblings, 1 reply; 5+ messages in thread
From: Eric Abrahamsen @ 2018-07-25 22:11 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: catching keyboard-quit from read-char
2018-07-25 22:11 catching keyboard-quit from read-char Eric Abrahamsen
@ 2018-07-26 20:03 ` Eric Abrahamsen
2018-07-27 16:00 ` Noam Postavsky
0 siblings, 1 reply; 5+ messages in thread
From: Eric Abrahamsen @ 2018-07-26 20:03 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: catching keyboard-quit from read-char
2018-07-26 20:03 ` Eric Abrahamsen
@ 2018-07-27 16:00 ` Noam Postavsky
2018-07-27 17:15 ` Eric Abrahamsen
0 siblings, 1 reply; 5+ messages in thread
From: Noam Postavsky @ 2018-07-27 16:00 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: Emacs developers
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).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: catching keyboard-quit from read-char
2018-07-27 16:00 ` Noam Postavsky
@ 2018-07-27 17:15 ` Eric Abrahamsen
2018-07-28 1:13 ` Noam Postavsky
0 siblings, 1 reply; 5+ messages in thread
From: Eric Abrahamsen @ 2018-07-27 17:15 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: catching keyboard-quit from read-char
2018-07-27 17:15 ` Eric Abrahamsen
@ 2018-07-28 1:13 ` Noam Postavsky
0 siblings, 0 replies; 5+ messages in thread
From: Noam Postavsky @ 2018-07-28 1:13 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: Emacs developers
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-28 1:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-25 22:11 catching keyboard-quit from read-char Eric Abrahamsen
2018-07-26 20:03 ` Eric Abrahamsen
2018-07-27 16:00 ` Noam Postavsky
2018-07-27 17:15 ` Eric Abrahamsen
2018-07-28 1:13 ` Noam Postavsky
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.