Re: Input for TTY menus

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Sep 2013 10:33:10 -0400
> 
> > 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.

Blocked input, that's why.  (In fact, 'select' did return, but
wait_reading_process_output would loop forever, even though 'select'
indicated that input is available.)  This is because menu.c calls
'block_input' before invoking the terminal-specific menu display
function; for the TTY menus, it doesn't make sense to block input,
obviously, since we are going to read keyboard/mouse input through
normal Emacs input channels.