[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perha
From: |
Chet Ramey |
Subject: |
Re: [Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perhaps elsewhere |
Date: |
Mon, 25 Jun 2012 16:31:21 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 |
On 6/24/12 6:08 PM, Max Horn wrote:
> Dear GNU readline team,
>
> I would like to report on an issue with readline 6.2 on Mac OS X 10.6.8 which
> does not occur with 6.1 and older. I also have reports for this on 10.7 and
> also on older Mac OS X systems.
>
> To reproduce the issue,
> 1) compile the attached sample program (or any other program that sets
> rl_event_hook),
> 2) run it inside Mac OS X' Terminal.app,
> 3) paste some text, e.g. this line.
>
> What happens is that you can see the text slowly appear, character by
> character, like in a bad sci-fi flick. Pressing any key will cause the
> remaining text to appear instantly.
>
> I traced this back to the change in input.c, in rl_read_key(), from 6.1 to
> 6.2. You see, on Mac OS X, if you paste a string, then all characters are
> instantly visible as input to the program. So, if you paste 50 chars, you
> will see 50 chars pending on stdin. Now when rl_event_hook is set, then
> rl_gather_tyi() is used to read pending input. This function proceeds to read
> all 50 pending characters at once. Previously, readline would then proceed to
> feed this input to the program. Specifically, this is the old loop:
>
> while (rl_event_hook && rl_get_char (&c) == 0)
> {
> (*rl_event_hook) ();
> RL_CHECK_SIGNALS ();
> if (rl_done) /* XXX - experimental */
> return ('\n');
> if (rl_gather_tyi () < 0) /* XXX - EIO */
> {
> rl_done = 1;
> return ('\n');
> }
> }
>
> But in 6.2, this was changed to the following:
>
> while (rl_event_hook)
> {
> if (rl_gather_tyi () < 0) /* XXX - EIO */
> {
> rl_done = 1;
> return ('\n');
> }
> RL_CHECK_SIGNALS ();
> if (rl_get_char (&c) != 0)
> break;
> if (rl_done) /* XXX - experimental */
> return ('\n');
> (*rl_event_hook) ();
> }
>
> The effect being that now rl_gather_tyi is going to be called 50 times or so.
> But only on the first time is there pending input. In the remaining calls,
> there is no pending input, and hence the select() call runs into the 0.1
> second timeout. So it takes ~5 seconds for the pasted 50 characters to
> appear. Ouch.
>
> For now, on my local system, I simply reverted to the old code. But I suppose
> you guys had a good reason to change it in the first place... So I'd
> appreciate if you could tell me what a "proper" fix for this might look like
> :-).
The change was made because the old readline 6.1 code makes it hard, if not
impossible, to use the event hook on input timeout (e.g., wait for input
for rl_set_keyboard_input_timeout milliseconds, then run a hook function).
I got several bug reports about that. A change will have to take both use
cases into account. I think that can be done, but it will take a little
while.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU address@hidden http://cnswww.cns.cwru.edu/~chet/