#2139 sleeping wx beauty without readline

[Martin Saturka]

When compiled gnuplot without readline, and run it under Linux (regardless whether interactively at a terminal, or via pipe), setting terminal to wxt leads to plots that do not update on user actions (meant in the plot window).

Neither buttons respond on clicks, nor bound events execute when the clicks/keypresses are done.
Only when I do anything in the respective terminal (if there is one), the wxt plot window updates: for both mouse click and keypress events.

It is this bad for versions 5.2.5 and 5.2.6. For version 5.2.4 I get responses on clicks, though keypress events need still terminal actions (and it even segfaulted after some random actions). Versions 5.2.0 and 5.2.2 even did not compile with readline disabled (linking phase got wrong on non resolved symbols). I have not tried 5.2.1 and 5.2.3 versions.

[Martin Saturka]

When at qt-terminal it is actually half-sleeping too.
While plot window reacts on clicks to its buttons, bind events are only effected after an(y) action in terminal. This is again under Linux/Ubuntu.

[Ethan Merritt]

For me both 5.2.6 and current 5.3 tip build without errors after
configure --with-readline=builtin
Both respond to keystroke and mouse events in the plot window as they do with libreadline.

Is that what you meant, or did you really do ./configure --without-readline?
I cannot think of any reason to do that, but nevertheless I get no compile time errors. The program does catch keyboard events in the plot window although as you say it does not respond to mousing operations until the next command prompt. I am always game to fix code that can segfault, but I think it is fair to say that anyone who wants to use gnuplot interactively should not configure --without-readline. Especially because the terminal driver libraries drag in libreadline anyhow :-)

[Martin Saturka]

Oh no, there were no compilation errors, no segfaults, it was OK. And yes, I compiled it with ./configure --without-readline. The way how I came to that is as follows:

• we had that issue with eaten lines after closed figure when run via pipe
• you solved it by one more case for "\n" being put in, i.e. a symptom chasing
• I would prefer to deal with the cause, and the cause is readline, as you told me
• thus may be that disabling readline in pipe-wise environments would solve it too
• thus I compiled gnuplot really without readline, and it did not eat my line then
• but it did not respond on key strokes (until a new line is sent) even when run via a pipe
• i.e. it solved the eating issue, but it caused a new issue

I do not actually need gnuplot without readline, as the "\n" pushing solves the original issue too. I've just thought about it as described above. Thus if it is expected behavior, you can close it.