Re: Key layout

[Daniel J S. <dan...@ie...>]

OK, I'm done with the key layout, unless there is something people want added.  I suggest adding this patch soon.  Syntax is good, I think.  The code is cleaner than the current.  We can touch up and loose ends rather easily after the fact.

The 3D key box may not be as robust as 2D (still works the same for the demos), but I say let's cross that bridge when we come to it.  (I'd propose unifying 2D/3D as a better alternative than attempting a complete revamping of 3D key.)

The 'all.dem' will show three or four plots as slightly different.  For example, in the current CVS version, simple.dem has:

set key outside below
plot [-5*pi:5*pi] [-5:5] real(tan(x)/atan(x)), 1/x
pause -1 "Hit return to continue"

set key left box
set autoscale
set samples 800
plot [-30:20] sin(x*20)*atan(x)
pause -1 "Hit return to continue"

Currently, that "set key left" seems to do nothing at all, as it may not make sense in the current cvs.  (The key stays "below" from the previous plot.)  The new setup will position the key below and to the left.

Something that is strange in current CVS is prob.dem:

set key bottom outside
plot [0:2] [0:1.1] a = 2.0, n = 1, sine(x) title "a = 2.0, n = 1", \
                   a = 2.0, n = 3, sine(x) title "a = 2.0, n = 3"
pause -1 "Hit return to continue"
set title "sine CDF"
set key top left
plot [0:2] [0:1.1] a = 2.0, n = 1, csine(x) title "a = 2.0, n = 1", \
                   a = 2.0, n = 3, csine(x) title "a = 2.0, n = 3"

puts the key of the second plot at the *inside* of the plot.  Now that seems like a silly behavior to be backward compatible to.  (For the synonyms "above", "below", "under", "over" assuming a position is fine, but not the more abstract "top left".)  I'd suggest changing prob.dem to "set key top left inside" if the plots in that demo are to remain as is.

I looked at the set_label() code Hans pointed out.  That is a creative way of implementing conflicting keywords (and I notice that nothing is changed until the whole line syntax is verified).  However, I'm going to leave the warnings I implemented as is; for two reasons.  One, what I've done is slightly more flexible if detailed warnings are desired.  Two, the warnings (as opposed to error) will not cause the "outside below" of the above example to fail during the demos.  We then have examples of doing this a variety of ways and can discuss pros/cons on the list.

So, the July 7 patch should do nicely.

Dan