New command window widget

This works for me on Ubuntu 20.10 and Windows 10.
For some reason, the command history is empty when I start with that option.

Being able to enter any characters on my keyboard without the fear of crashing the command window (on Windows) is a huge improvement imho.
I wouldn’t even mind if input and output were separated (like they currently are with the experimental terminal widget) if implementing a combined input/output widget turns out to be difficult.
I’d find it more convenient if the input line was below the output text box though.

It would also be nice if the font was used that was set for the command widget in the preferences.

The only major drawback (and possibly the only point why I wouldn’t start using it on a daily basis just now) is this point you mentioned:

When that point is resolved, we could set the new terminal widget as the default imho (at least on Windows).

Would it be possible to have an option in the preferences to select with which terminal widget the GUI should start by default?

Support for readline in the input line would also be nice to have.

I am going to merge the addon-patch from my comment on Dec 27 to the new command-widget. It implements the usage of some terminal preferences, moves the input line to the button, and adds some style polishing.

While testing the new pause feature, which works perfectly when running a script, I noticed two issues:

  1. There is no way to know whether Octave is waiting for input or already running some command: Currently the [in] prompt only appears at the beginning of lines that have already been executed. I understand that having a read-only prompt at the left-hand side of the input line is not easy, but having an indication that Octave is actually waiting for input would help. At least the input line should not be editable while the interpreter is already running.
  2. Octave may fail understanding some partial command:

I tried to run the following infinite loop at the command line, one line after the other:

while (true)
a=rand (1);

And here is what I obtain in the terminal:

[in]: while (true)
a=rand (1);
[in]: end
error: parse error:

  syntax error

>>> end

For some reason, the third line is actually interpreted as a single command, out of the context of the two previous ones. Note that adding another line, e.g. "b = 2;" before the end keyword makes it work.

I have pushed the patch for reading terminal settings and moving input box to the bottom with cset octave: d6b2d9f9e1e0

I’m fairly sure that feature worked properly at one point, so maybe I broke it with some other change. I’ll try to check it out and fix.

The [in] marker in the output window is just there to show that the line is input, not output.

If you enter something like for i = 1:10 in the input text box, you should see the prompt change from >> to > to indicate that more input is expected. It should stay that way until the statement is complete, but as you noticed, if you enter another line like disp(i) then the prompt goes back to >> indicating that the interpreter is confused about the current input state.

Also, having separate input and output windows is only temporary. I have no intention of leaving it that way. It was just easy to implement for this initial experiment.

I pushed the following change:

I’m now able to enter multi-line input and it appears to work correctly.

If I execute something like for i = 1:100, i, pause (1), end at the command prompt, then I am able to use the [stop] button to interrupt the execution and jump back to the prompt, though that action is not immediately obvious because there is no indication in the input or output window that the interrupt occurred.

For that same loop input at the command line, I’m also able to use the [pause] button to interrupt the interpreter and enter the debugger. But again, there is no clue in the input or output windows about that. From there, the [continue] button resumes execution, as will dbcont at the command prompt.

If those same commands are place in a script file and the script is executed, then the [pause] button again enters the debugger and the script file is opened in the editor window and the usual debugger interactions work there with an arrow indicating where the evaluator is currently paused. In this case a “stopped at” debugger message is displayed in the output window but the GUI doesn’t switch to the editor window.

I’ll see whether I can at least fix the prompt so that it switches to “debug>” or similar and provide some feedback about interrupts happening.

make check fails for me at hg id b65824235c7f during the first test in
Possibly related to that change.

Oops. You’d think by now I would know better than to push a change like that without at least attempting to run some tests…

I pushed a more limited change: