Re: [Bug-readline] Pasting long lines is slow

[Chet Ramey]

On 5/21/15 5:44 AM, Ole Laursen wrote:

> I've been thinking about batching the input as it seems like an easier
> fix compared to rewriting update_display. So I inserted a log into
> insert_text:
> 
>   FILE *inserttextlog = fopen("inserttext.log", "a");
>   fprintf(inserttextlog, "%i\n", l);
>   fclose(inserttextlog);
> 
> And it looks like each character is indeed inserted one-by-one since
> readline is reading them one-by-one from the input stream. There's a
> _rl_insert_typein called from _rl_insert_char which looks like it's
> actually taking care of a similar case of a series of rl_insert
> characters, but only for stuffed characters and not for multibyte
> cases.

Yes, readline doesn't try to read more than one character ahead.  It
should not grab input that is intended to go to another process, and
it needs to process each character to see whether or not it is an
editing command, a character to be inserted, or the end of input.

Multibyte characters are handled by a loop in _rl_insert_char; characters
are still read one at a time, but this suppresses redisplay until an
entire multibyte character is consumed.

> I suppose one could try to generalize the _rl_insert_char code to grab
> any rl_insert characters waiting in the input stream. Or just always
> stuff everything waiting in the input stream.

The first is a reasonable approach, but _rl_insert_char is the wrong place
to do it.  The second is totally wrong.

> Or decouple the display update from the line buffer modifications. The
> update could then e.g. be driven from the input stream reader.

It's already decoupled, as I explained in a previous message.  You just
want it to be called less often.

> Or rewrite the call chain leading to _rl_insert_char so that it can
> take a string and not just a single byte.

I did a couple of things.  I added an inline _rl_wcwidth function that
returns 1 for all printable ASCII characters and calls the system wcwidth
for the rest.  That should help, though it doesn't do anything for
characters between 128 and 256.

The second thing is this experimental patch to text.c that uses the
heuristic you suggested: it assumes that a call to rl_insert will be
followed by other calls to rl_insert and tries to read ahead in the
input stream as long as the character read maps to self-insert.  I've
attached that for folks to experiment with.

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/

readline-optimize-insert.patch
Description: Text Data