there seem to be a number of items rolled up into this report, not reflected in the title.  regarding the title issue, in Octave 9.0.1 (hg id: 14cb31ec0251) I am unable to reproduce the issue where panning (scrolling) with a plotyy figure results in unsynced panning or the plot being 'lost' in either the 'qt' or 'fltk' toolkits. I can reproduce only using the 'gnuplot' toolkit. (create the simple plot from comment #3, and use the middle mouse wheel to 'scroll' the graph vertically. the first plot is lost.) the same mouse scrolling behavior doesn't seem to work the same way in the other toolkits, and any other method of panning seems to keep the two plots sync'd.

there were other items discussed related to these plots, but there doesn't appear to have been any progress made on them in over a decade. 

As we effectively deprecated gnuplot some time ago and more recently have done the same with fltk (issuing a usage discouraged/toolkit not maintained warning on load), and it seems that there is nothing left to do here for the qt toolkit, closing as Won't Fix.  Can be reopened if the primary issue can be reproduced on qt, or if someone wants to take up the task of working on the other toolkits.  Any other issues should be addressed in other, more specific reports.

This bug still appears to affect Octave 4.2 and the development version using gnuplot 5. Does anyone interested in gnuplot intend to work on this or close as won't fix?

OK , so most of the fundamentally flawed design seems to be inherited from MAtlab. I've never used it so I can't compare. I suppose you're stuck with that.

However, I find it rather surprising that you think NOT having plot lines and axes disappear when strolling or zooming is a "feature request".

I assume matlab does not loose plots and axes.

What does matlab do if you redefine x axis markers and ticks? Do you get a messy superimposition of the new and old axes?

Definitely looks like there are issues that need to be looked at here.

Whether anyone has time or motivation is another question.

see gnuplot>help axes

current octave plots could be done on x1y1 and x1y2 , removing the redundant x2 clone lying under x1 could have several advantages.

1/ a useful second x axis available as needed

2/ ability to redefine x1 ticks without having to repeat the operation on the useless x2 to avoid making a mess.

making xlabel , ylabel commands explicit rather than depending on some ephemeral state " last used axis" which is not directly visible (and often undocumented when it is changes) would make robust scripting easier.

set x2range [0:20]; set y2range [0:100]; f1(x)=x; f2(x)=x*x; set x2tics; set y2tics; plot [0:10] f1(x) axes x1y1 ,f2(x) axes x2y2


I have made several references to this feature in the other bugs I've posted recently. I glad to see this has now reached critical mass.

I hope that helps you see clearly how this can be done in gnuplot.

You will notice all four axes are completely independent and the scroll feature scrolls both in unison and without either line disappearing.

HTH

When I said "gnuplot does not do this" I was referring to the buggy behaviour just described in the previous sentence.

To be explicit: octave calling gnuplot exhibits the described problem. Using gnuplot directly on the same system does not lose lines when scrolling in either single or double axes plotting.

 x=[0:10];y=x;
 plotyy(x,y,x,-y)

then scroll with arrow key or mouse wheel. First mouse/key scroll event and the first plot line vanishes, as described.

On looking more closely at this, I notice this is more of the "last axis used" paradigm bugginess.

It seems the scrolling and redraw is only communicated to the y2 axis and plot. Not only does the x1,y1 plot disappear, so do those axes!

"An" x axis remains but this is probably the undocumented and identical x2 axis, I'd bet money the x1 has gone as well.

This only emphasises my existing criticisms of plotyy and the last axis syndrome.

PS , the p hotkey reverts the scroll as in gnuplot but does not recover the lost plot.