Re: Release plans: Version 4.4.4 and beyond

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 13 September 2011, Hans-Bernhard Bröker wrote:
> On 13.09.2011 23:59, Ethan A Merritt wrote:
> 
> > - The PostScript terminal driver is inconsistent with all other terminal
> >    drivers with regard to the "set size" command.
> 
> ... that's true in no small part only because you bodily removed a good 
> number of other drivers that behaved the same way.

Terminals removed since version 4.0:
    amiga apollo atari fg gnugraph gpr iris4d mgr multitos
    png(libpng) rgip unixplot

None of those have been remotely relevant for the last decade.
Who cares now what they did about "set size"?

> > - The pieces are in place to support "dashtype" as a line property.
> >    The current syntax overloads "linetype" to mean a combination of dash
> >    properties, color properties, and width.
> 
> That one had me completely puzzled when I (belatedly) saw it mentioned. 
>   What was so bad about 'set style line' that its functionality needed 
> to be duplicated and incompatibly overloaded onto pre-existing syntax?

Clarify please. Nothing has changed about 'set style line' that I know of.

> Since the addition of 'linecolor' ages ago, 'linetype' already controls 
> basically nothing but dashtype.  What would be the benefit of changing 
> the name?

I think we're talking at cross-purposes.  The issue is that if you write
a script that refers to linetypes, it does different things depending on
whether you say "set term post solid color" or "set term post dashed mono".
The terminal itself changes how linetype is interpreted.  

The other point is that you can [now] force the color regardless of the
terminal's own defaults.  But there is no way to force the dash type;
you can only use the terminal defaults.

> It would be a good deal less intrusive to add a new sub-command to 'set 
> style' that just turns off the influence of linetype numbers on the 
> default(!) line colours.

Less intrusive than what?

> > - The "call" command no longer makes any sense, and arguably is broken.
> >    (I can't find the discussion we had about this, but it must have been
> >    about 2 years ago?).
> 
> I have not the slightest memory of such a discussion ever having taken 
> place.  Nor do I see how call might no longer make any sense.

Variables are persistent across 'load foo' anyhow.  There is no need
for a separate mechanism 'call foo var1 var2 var3'.
Brokenness: the call mechanism does not handle strings (understandable
since they didn't exist at the time it was written).

	Ethan