|
From: | Daniel J Sebald |
Subject: | Re: 300 baud V.21 terminal emulation |
Date: | Fri, 04 Oct 2013 02:29:09 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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.htmlit'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-parenthesesFrom 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 off2) 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 offand 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
[Prev in Thread] | Current Thread | [Next in Thread] |