Yes, you are right. Closing report as fixed.

@Michael: Yes, the "x" is echoed and octave returns to prompt.

octave:3> pause
xoctave:4>

I am on linux mint 19 which has debian/ubuntu package libreadline7 (7.0-3).

@Michael: I cannot reproduce the hang, but at least I can reproduce the fact that characters are echoed in the terminal. The latter is for sure a side effect of the patch I pushed. I'll look into this.

@arb: Can  you confirm this report can be closed?

@arb: I attached an updated patch that handles "query". I opted for the static variable  even though, indeed, it would be nice to safely store this kind of  static variables into the interpreter object but it is probably part of another (bigger) task.

(file #45341)

@arb: I attached a patch in which I implemented this functionality in C++.

@jwe: Is it OK to use a static variable to store the state of the pause function or should I make it a more fundamental global variable (like other Vxxx variables)?

(file #45330)

I use for instance a workflow where I have a sequence of

plot
pause
print

possibly spread across multiple functions. When I am happy with the plots, I can then conveniently generate hardcopies, on Linux at least, in batch with the input redirection. Or for debugging purpose, if somewhere an error occurs, with the redirection you can progress more quickly to that spot.

Anyway I find myself using this redirection feature quite frequently, which probably is the reasons why I hit upon this side effect.

I could change pause calls to pause(xx) calls, and change xx to a small value for batch, but that is a little bit awkward with plots generated in different functions.

Matlab has the pause('on')/pause('off') feature with I guess would be suitable for this, but octave's pause does not provide that.

I tested the patch in 5.0.0.
Resizing does work now during pause, thanks!

However I do notice a side effect, on Linux, in combination with input redirection.

Save the script from the original submission as issue53729.m

then the following will show the plot

octave-4.4.1 issue53729.m < /dev/null

and on output:

ver = 4.4.1
hg_id = 7a7c31b93216+
ans = qt
<Enter> to continue ..
after pause ..

where as in octave-5.5.0

octave-5.5.0 issue53729.m < /dev/null

produces:

ver = 5.0.0
hg_id = e80a87f65997+
ans = qt
<Enter> to continue ..

and will not resume executing after the pause, remains executing the pause.

>>  Is that the expected behavior, that they are queued?

In most places the GUI uses gh_manager::post_set to change properties, so that the actual property changes only happen when the graphics events queue is processed.
There are exceptions though, in a few places we directly use graphics_properties::set after having locked the graphics mutex, or in the case of the "view" property we directly call axes::properties::translate_view. In that case, even though the property change takes effect immediately, listeners are queued  if the call has happened in the GUI thread (see https://octave.org/doxygen/4.4/d7/dd3/graphics_8cc_source.html#l10218) and the interpreter will still be called only when the graphics events queue is processed.

We want the graphics event processing to be triggered when one of those conditions is met:

• drawnow, figure, getframe, waitfor or pause functions are called. This is per Matlab compatibility (see e.g. the note here https://fr.mathworks.com/help/matlab/ref/matlab.graphics.axis.axes-properties.html#budumk7_sep_shared-Interruptible)
• The interpreter returns to prompt (idle state).

AFAICS the above works well in Octave. During the execution of "pause" though, we want event processing to happen regularly since menu actions should take effect as fast as possible. That is what the patch for this bug does.

In the example you provided, unless you add a call to drawnow, figure, ... or pause in the loop, the event processing won't be triggered. That is currently how it works and my patch doesn't change anything about that.

@jwe: I was bout to push this patch together with the patch for bug #54340 (which refactors graphics events handling).
I would like to be sure I understand your concern before making a decision. Could elaborate a bit and explain what problem you anticipate and in what situation?

What happens when a graphics event involves a callback function that requires the interpreter?  Can we guarantee that it is OK to execute a callback function when the interpreter is waiting inside another function call?

with this script

ver = version
hg_id = __octave_config_info__.hg_id
graphics_toolkit('qt');
% graphics_toolkit('qnuplot');
graphics_toolkit()
ezplot(@sin);
fprintf('<Enter> to continue ..\n');
pause
fprintf('after pause ..\n');

then invoked, with --persist as

octave-4.3.91 --quiet --no-init-file --no-site-file --norc --persist bp.m

which produces

ver = 4.3.91
hg_id = cf8bb17e7193+
ans = qt
<Enter> to continue ..
after pause ..

while the pause is active, all interaction with the plot is possible and works. A resize of the window however does resize the window, but not the plot. After the pause, returning to the command prompt, the plot can be resized.