#2200 [in]consistent use of -noreplotonresize

[Christophe Noisel]

I'm trying to create a create a multiplot which works at first, unfortunately when I replot (toolbar button, resizing window or zooming in anywhere) all the plots excepting the last one disappear. It makes impossible to manipulate the plot.
test case :

set multiplot
set size 1,0.4
set origin 0,0.5
plot sin(x)
set size 1,0.4
set origin 0,0
plot cos(x)
unset multiplot

I'm running ArchLinux and I've tried gnuplot 5.2 patchlevel 7 and gnuplot 5.3 patchlevel 0
Problem seems to happen as well with term set to qt or xterm.

I did not find any related tickets here but it seems to be linked with these reports here :
https://savannah.gnu.org/bugs/?53840
https://savannah.gnu.org/bugs/?38542

[Ethan Merritt]

Not a bug. That's the way it works. Gnuplot only has context to recreate the most recent plot command, so that's what you get from "replot". Any and all settings may have changed between "now" and the point when earlier plots in the multiplot were generated. You'd have to replay the history of the session to recreate the entire multiplot.

[Christophe Noisel]

All right, thx for the quick answer by the way.

[Igor Bray]

This is a relatively recent change. As far as I can remember, since the inception of multiplot, resizing the screen (as in going to full screen) would result in the multiplot being appropriately scaled. Now, as Christophe is finding, only the last plot of multiplot is displayed. For those of us who are using interactive displays, such as x11, it would be helpful if going to full screen did not destroy what was plotted.

[Ethan Merritt]

So far as I know, there has been no change to gnuplot in this regard, ever. This is the first I ever heard of the behavior you describe. I would guess that it was something done entirely by your window manager; i.e. it did the resize without ever telling gnuplot about it. If you can trace what event notifications the window is sending that it didn't used to send, maybe you can disable them? Or if they are distinctive enough to distinguish from other events like "close" or "exit" that gnuplot really does need to act on, maybe we could teach gnuplot to ignore them.

On the other hand, if you can reproduce a change between two known versions of gnuplot running under the same window manager, that would at least offer some hope of tracking down a change elsewhere in gnuplot that had an unintended consequence.

Could this possibly be the same issue as reported in Bug 2086?
https://sourceforge.net/p/gnuplot/bugs/2086/

The original reporter was able to reproduce it on demand, but the developers who looked at it could not reproduce it.

[Ethan Merritt]

I forgot to mention that for the x11 terminal in particular (which is a separate program from the core gnuplot program) there is a command line switch gnuplot -noreplotonresize and a corresponding terminal option set term x11 noreplotonresize. Does that make a difference for you?

[Igor Bray]

Yes, the "noreplotonresize" did the trick, thank you! By the way, this option does not come up on "gnuplot -h". Perhaps this is because it is specifically for x11. It is there inside the internal help system. Very grateful for the suggestion!

[Ethan Merritt]

The qt and wxt interactive terminals both have a toggle in the toolbar widget that has the same effect, but those terminals don't pay any attention to the command line switch nor do they have a corresponding "set term xxx" option. So it looks like there could be some unification of code as well as better documentation. I'll re-open this tracker item as a reminder that helpful changes could be made.