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

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

Ethan Merritt wrote:

> You misunderstood me.  I was proposing to replace the separate 
> TERM_TABLE entries with sub-options to term->private() or whatever
> this new API entry would be called.  So existing calls to 
> term->suspend()  would become calls to term->private(SUSPEND).

I'm wildly against this.  The term API is supposed to be "add-only".
Changes to existing calls, and certainly removals of entire entries, are
out of the question.

> ???   The point is that I cannot use them for the purpose of detecting
> such a change *in general*, because they are only called under certain
> conditions.

As I said: the number of conditions in which term->suspend() is called 
could, and possibly should be extended.  There's no really good reason 
why the plot would *have* to be interactive for term->suspend() to ever 
be called.  It may just take some more caution (e.g. those GUI drivers 
that have it trigger a graph window update may want to support 
incremental updates instead of full redraws).

  > Terminal drivers can test for "if (interactive)" on their own.

No, they can't --- the 'interactive' flag is outside the realm of the 
terminal layer, and should remain there.  Two drivers (amiga, post) 
already blundered ahead and referred to this global variable.  That's
a serious no-no.  It's practices like this that have kept gnuplot the 
tangled mess we're still facing.  Such abuse has to be *reduced*, not 
added to.