[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuplot-info-beta
Subject:    Re: Incompatible changes to command syntax...
From:       Petr Mikulik <mikulik () monoceros ! physics ! muni ! cz>
Date:       2001-11-27 9:07:07
[Download RAW message or body]

> For long 'plot' command lines, that's not going to help much, in the long
> run, I think.  They can easily have several lines and/or lots of datasets,
> so you have to navigate carefully anyway, even if the option order was
> relaxed.  In other words, allowing arbitrary order of options is solving
> only half the problem, for 'plot' and 'splot'.

If it solves half of the problem, then it helps a lot. And that's the reason
I've coded this.


> > mainly when I need it for
> > 	splot x*y with dots palette
> > 	splot x*y with points palette
> > When I needed this feature, it has taken me a lot of time to figure out
> > that the syntax is 'with dots|points lt palette' which I really find
> > confusing.
> 
> That's a documentation bug --- 'lt palette' simply never was documented
> properly, it seems.  One reason I like that syntax better is that it

Not only documentation bug. Actually, what it does, and ever did, is the
following meaning:
	splot x*y with dots color palette
	splot x*y with dots color lt 5
or
	splot x*y with dots color lt 5 color palette
Which means:
	colour of dots according to smooth palette
	colour of dots according to lt 5 colour
or
	colour of dots according to smooth palette, but if the driver does
		not support palette, then use lt 5

> That's also wrong in how you document the shortened version, IMHO:
> 
>  Syntax:
>        set style line <index> {linetype | lt <line_type>}
>                              {linewidth | lw <line_width>}
>                              {pointtype | pt <point_type>}
>                              {pointsize | ps <point_size>}
>                               {palette}

This syntax is correct: if palette not supported by terminal, use lt <n>.


Moreover, if we are going to support colour labels and other text, then the
syntax would probably be

	set label 1 "colour" at 1,2,3 color palette
	set label 1 "colour" at 1,2,3 color lt 6
and not
	set label 1 "colour" at 1,2,3 lt pal
which seems to me very strange.



> > > OTOH, 'plot' could well be argued to need a fixed order of options. E.g.
> > > we already came across the suggestion before that it may be worthwile to
> I know.  This came up as a rather longterm plan.  The idea is to further
> break the datafile manipulation stuff ('every', 'using' and 'smooth' for
> the start, plus eventually fixed axis range clipping, contouring and

Ok, you mean that the datafile operation could, in a later version of
gnuplot, depend on these 5 options:
	every using smooth every using
Every and using are always commutative, together with index, binary,
matrix... In the current version of gnuplot, smooth is evaluated on the
'plot' level, ie after the datafile options are read, i.e. neither in my
'commutative patch' the combination
	plot smooth every using
is not allowed --- see my previous post:

Enclosed is a patch that allows any order of options in plot and splot
commands. Actually, 'any order' applies separately to the group of 
options for a datafile [see df_open() in datafile.c]
	every matrix binary index thru using
and plot commands [see plot2d.c]
	smooth title notitle axes with
or splot commands [see plot3d.c]
	title notitle with

This means that my patch does not break anything and can be submitted. If it
is later decided to support every and using *after* smooth, then it will be
the matter of plot command options [see plot2d.c]
	smooth title notitle axes with {every} {using}


> Position independence only makes sense for options that take effect all at
> the same time, as an inseparable group.  The line/point styling options
> are the typical candidate for that.  
> 

> > 	while (1) {
> The 'while(1)' would be replaced by an, IMHO even clearer
> 	while (! END_OF_COMMAND) {

Yes, it could / should.


> Ceterum censeo: we really should think about using a grammar-driven
> parsing engine sometime soon, now :-)

I never used such a tool. Wouldn't it break gnuplot compilation on machines
without these tools?

---
Petr Mikulik



[[[[ unsubscribe from info-gnuplot-beta via majordomo@dartmouth.edu ]]]]

[prev in list] [next in list] [prev in thread] [next in thread]