[Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perhaps elsewhere

[Max Horn]

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



By the way, I personally observed this bug originally with the GAP computer 
algebra system <http://www.gap-system.org/>, but found other mentions of it on 
the net. E.g. ruby seems to be affected as well:

http://stackoverflow.com/questions/7296169/pasting-text-into-irb-is-incredibly-slow-readline-issue
http://stackoverflow.com/questions/5624740/rails-console-running-incredibly-slowly-when-editing-text


Cheers,
Max

minirl.c
Description: Binary data