Hi, On Mon, Jul 22, 2013 at 5:56 PM, Chet Ramey <[email protected]> wrote: > On 7/22/13 11:53 AM, Margarita Manterola wrote: >> On Mon, Jul 22, 2013 at 5:42 PM, Chet Ramey <[email protected]> wrote: >>> I spent a bunch of time looking at this and concluded that the problem was >>> the result of changing the terminal modes from cooked to raw and back at >>> every line boundary. >> Who is doing this change? > readline does it. That's how readline is able to read a character at a > time.
Ok, I think I understand your explanation now. The change in readline done at every end of line takes enough time that when there are enough line breaks, the buffers don't get emptied quickly enough. Is that it? In my tests, it does seem to matter how many enters I have in my test input, so I guess it makes sense with what you are saying. >>> The workaround is to turn off line editing (and the terminal mode >>> switching) before pasting a large number of characters into the input >>> buffer. This has been tested and works. >> Can you elaborate a bit more on this, please? > Sure. It's application-specific. In bash, for instance: > set +o emacs +o vi I see, but what about programs that are just using readline, like the one in the example? Should every program be patched so that users can say "I'm going to paste a lot of data"? I think that readline should be patched so that this doesn't happen. Do you think it's not possible to fix it? -- Thanks, Marga _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
