Re: [ gnuplot-Patches-1191202 ] Fix multiplot problem with epslatex terminal

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

Ethan Merritt wrote:
>Comment By: Hans-Bernhard Broeker (broeker)

>>The idea of a multi-function term->private is flawed, IMHO.
>>Even the name is, to some extent.  I had reasons to suggest
>>calling the one being invented here term->startlayer() instead.

> That is essentially what I proposed originally, and I understood
> you to be opposed to it at that time.

The problem I wanted to comment on here was that term->private() would 
be a good deal worse than term->layer().

>>A new API entry like the above would, effectively, specialize the
>>interface to gnuplot as the client, and kill all remaining hopes of one
>>day splitting up the program into well-separated layers of functionality.

Well, API design is tricky.  You have to make sure that the API is 
expressive enough to support all that needs to be done without such ugly 
hucks as are currently used, but still simple and well-defined enough 
that it can actually be used with some confidence.  A multi-function 
term->private() would violate all these ideas almost maximally.

> binary.  Since every new terminal API call introduces a function
> pointer slot into ~50 driver entry tables, I would have thought you
> to oppose proliferation of new terminal API functions. 

I do indeed oppose proliferation (it works against the "simple" 
criterion).  But that doesn't mean I want to oppose any and all extensions.

The strategy should be: _think_ before adding a new terminal entry: is 
this really something for the terminal driver to handle? And: what 
should the core do if this function is not implemented?  OTOH, a new 
terminal entry is always better than terminal-dependent code having to 
smuggled into the core.

> But if that's the way you prefer to go, then I see an argument for
> at least three new API calls to cover existing use:
>  term->layer(int layer);
>  term->comment(TBOOLEAN global_or_inline, const char *comment_text)
>  term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g)

I'm not sure about comment(), but the other two would make sense, I think.

But I'm unconvinced that "begin next plot in a multiplot" is a signal 
that should be sent through a function called term->layer().  Layering 
is supposed to be about drawing order (front vs. back), whereas 
multiplot is about grouping.