Re: terminal API: Intent of multiplot suspend/resume?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> Yes.  But term_check_multiplot_ok()  itself is only called in
> interactive mode.  

Ooops, should have checked that.

Well, given the new evidence, either its interface is quite completely 
wrong, or it's not used in the way.

So, let's see what my conclusions would be so far:

* This is not a particularly urgent issue.

* Removing suspend()/resume() completely would be a Very Bad Idea[TM].

* suspend()/resume() could help more if they were called in more cases, 
but probably should not be called in non-interactive mode to avoid 
excessive redraws.  Benefits could include drivers that want to know 
which graphical elements belong to which plot, for grouping purposes. 
SVG, e.g., could usefully open a new group for each plot of a multiplot 
page, for more meaningful manipulation by third-party tools.

* The above may necessitate a factorization of what suspend() does into 
two jobs: informing the driver that a new plot in a multiplot has 
started, and telling the driver that the interactive user now needs the
text interface, not the graphics, to be shown.

* TERM_CAN_MULTIPLOT shouldn't decide on whether or not term->suspend() 
gets called at all.  It may be superfluous, i.e. replacable by a test 
that term->suspend() and term->resume() exist.

* TERM_CANNOT_MULTIPLOT has to be tested earlier than it is, possibly 
from inside "set multiplot" itself.

* we may need a way to have redirected stdin sources decide for 
themselves whether they want to act like interactive or not, as far as 
multiplot is regarded --- the command source could itself be 
interactive, or it could just be a script generator, and currently 
gnuplot has no way of distinguishing between the two.