emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Input for TTY menus


From: Stefan Monnier
Subject: Re: Input for TTY menus
Date: Thu, 19 Sep 2013 10:33:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> 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 (probably after setting up some
overriding-terminal-local-map).

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

> Note that read_char is called recursively here, because x-popup-menu
> is itself called from read_char.  Is it possible that read_char does
> not tolerate recursive calls?

I don't think so: read_char_minibuf_menu_prompt also calls
read_char recursively.

> Just in case it matters, here's the interesting part of the backtrace
> recorded when read_char was called from the menu code (some functions

Looks reasonable, sorry.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]