[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