[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: |
Sat, 21 Sep 2013 17:56:34 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> 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.