[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Input for TTY menus
From: |
Eli Zaretskii |
Subject: |
Re: Input for TTY menus |
Date: |
Thu, 19 Sep 2013 18:47:04 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Thu, 19 Sep 2013 10:33:10 -0400
>
> > convert them into appropriate movements/selection in the menu. We
> > should support not only the C-f/C-b/C-n/C-p keys, but also the arrow
> > keys which typically produce more-or-less arbitrary escape sequences.
>
> > Which of the Emacs input routines should I use to get this to work?
> > There's a gazillion of read_SOMETHING functions in keyboard.c. After
> > some reading of the code and the commentary, I decided that read_char
> > is the one I need, as it seems to be capable of both reading
> > single-character keys and mouse events. Is there a better function?
>
> read_char won't handle the arrow keys. To handle the arrow keys you
> need to use read_key_sequence
Thanks. This means I'll probably need to clone some small subset of
the code in command_loop_1 after it calls read_key_sequence, in order
to process the key sequence, right?
> (probably after setting up some overriding-terminal-local-map).
What would be the purpose of overriding-terminal-local-map in this
case?
> > Anyway, an attempt to use read_char didn't succeed: when that function
> > is called after dropping down the first menu, Emacs gets stuck inside
> > 'select', which never returns, no matter how many keys I press.
> > (Well, it will probably return after 100000 sec., but I didn't wait.)
> > IOW, when called in this manner, read_char somehow doesn't sense that
> > keyboard input arrived.
>
> That's odd. But I can't think of any reason why this could
> happen, sorry.
OK, I will keep digging.