bug-readline
[Top][All Lists]
Advanced

[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/





reply via email to

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