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.