Re: slow input

[Rik]

On 04/02/2013 02:59 PM, address@hidden wrote:
> Message: 2 Date: Tue, 02 Apr 2013 17:38:17 -0400 From: "John W. Eaton" <address@hidden> To: Daniel J Sebald <address@hidden> Cc: address@hidden Subject: Re: 300 baud V.21 terminal emulation Message-ID: <address@hidden> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 04/02/2013 05:24 PM, Daniel J Sebald wrote:
>> > When copying a command into the IDE/GUI terminal that has a lot of non
>> > alpha-numeric characters such as parentheses and brackets, the
>> > processing is really slow. Something like this:
>> >
>> > qtinputdlg ({"Einstein:","Newton:","Planck:"}, "Most General Example",
>> > [1 7; 1 11; 1 20], {"E = m c^2","F = G m1 m2 / r^2","B = 2 h v^3 / (c^2
>> > (e^(h v/(k T)) - 1))"})
>> >
>> > takes several seconds to process. A stream of text zips in up to the
>> > closing bracket, then stops for a half second. Then another stream of
>> > text until a bracket is encountered. Etc.
>> >
>> > Copying into a shell command line is speedy in the most recent source.
>> > However, I think I've seen a similar sort of thing even when not running
>> > the GUI on a version from a couple weeks ago.
>> >
>> > Does anyone know why that is happening?
> There are a couple of possibilities.  One is a bug in readline that
> we've discussed before.  It's been fixed in the readline sources, and a
> patch is available, but I don't think there is a released version of
> readline with the fix quite yet.  A new readline and bash should be
> happening relatively soon though.
>
> However, the bug in readline would affect all text if there is a
> readline event hook installed.  So if you are seeing the problem only
> when there are parens or brackets, then maybe it is a delay while
> readline does paren and bracket matching?
>
> What happens if you put
>
>    set blink-matching-paren off
>
> in your ~/.inputrc file and restart Octave?

Alas, this doesn't work for me.  I can reproduce the problem with simple text without punctuation.

If I use the three lines below as a test then the first two are processed instantly and the third takes a good long while to print character by character.

--Cut--
this is very long text
this is very long text
this is very long text
--Paste--

The interaction is clearly between Readline and whatever else might be using the readline loop.  For example, I can start without the GUI (no readline) and pasting text works.  But if I execute 'graphics_toolkit fltk' then subsequent pasting is slow.  Returning to gnuplot after fltk has been initialized does not clear the slow pasting so something quasi-permanent is left in place.

--Rik