Re: 300 baud V.21 terminal emulation

[Daniel J Sebald]

John,

I built Octave on a new system and came across this issue with readline 
and slow pasting again.  There is no new bug here, just that it took me 
a while to remember what the issue was.  In terms of the upcoming 
release, I wonder if users will come across the same issue often. 
Unlike us, they won't have much of an idea of what is happening, but 
will be unhappy with the slowness of the readline pairing parentheses.

I looked into readline/bash a bit and believe it might be possible for 
Octave to configure this, turn it off by default and perhaps have a 
settings option in the preferences.

I'm not quite sure of how the terminal emulation is launched and under 
what environment it falls, but according to the documentation

http://www.gnu.org/software/bash/manual/html_node/Readline-Init-File.html

it's possible to set an environment variable INPUTRC to take the place 
of .inputrc.  So I'm thinking that Octave could create a template 
"inputrc" if there is no such thing on the user's system and turn off 
blink matching.  There is a way to force an active terminal to reinitialize,

http://www.superuser.com/questions/213872/bash-readline-blink-matching-paren-not-blinking-matching-parentheses

From that it seems Octave can then modify blink-matching behavior 
without having to relaunch the terminal (or Octave).  The steps would be 
something like:

1) Octave looks for, say, .octaveinputrc.  If it doesn't exist, create 
it with the contents

set blink-matching-paren off

2) Octave sets the environment variable INPUTRC to .octaveinputrc before 
launching the terminal emulator.

3) In Octave's options, if the user changes the setting for 
blink-matching, Octave can simply change .octaveinputrc to

set blink-matching-paren off

and then force a Ctrl-x Ctrl-r into the terminal emulator to make it 
reread .octaveinputrc.

Dan


On 04/02/2013 04:38 PM, John W. Eaton wrote:
> 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?
>
> jwe

--

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com