gnuplot-beta

multiplot doc spelling errors

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

Attached is a patch to fix spelling errors in the mulitplot documentation.

Also, I notice in this documentation that

?nomultiplot

is a means to access this text.  Perhaps all the cases of

?no<keyword>

that appear in gnuplot.doc can be moved under the same heading

?nomultiplot
?noarrow
etc.

Deprecated syntax.  Use `unset <keyword>` instead.

Re: multiplot doc spelling errors

[Petr M. <mi...@ph...>]

> Attached is a patch to fix spelling errors in the mulitplot documentation.

I will commit it, with yet another fix to "will a produce".

However, I have one more major point there:
Docs says:
 This grid is filled rows first or columns first depending whether
 `rowmajor` or `columnmajor` is given by the subsequent option of the
 multiplot command. Default is `columnmajor`.

That's confusing: either words in the above are opposite, or "major" does
not mean "the slower scan in filling". Currently, it works this way:
"rowmajor" fills columns first, "columnmajor" fills rows first. It should be
said explicitly e.g.

 This grid is filled rows first or columns first depending whether
 `columnmajor` or `rowmajor` is given by the subsequent option of the
 multiplot command, respectively.

Or should the keywords be renamed to e.g. "rowsfirst" and "columnsfirst"?


And yet another observation:
If a wrong option is given, e.g.
       set multiplot layout 3,2 blacolumnmajor
produces error message:
    did not expect anythig here
Firstly, there should be "anything". Secondly, the message is not
very well descriptive. What about "wrong option" instead?

Petr

Re: multiplot doc spelling errors

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

Petr Mikulik wrote:

>>Attached is a patch to fix spelling errors in the mulitplot documentation.
>>    
>>
>
>I will commit it, with yet another fix to "will a produce".
>

Yes, another typo.

>However, I have one more major point there:
>Docs says:
> This grid is filled rows first or columns first depending whether
> `rowmajor` or `columnmajor` is given by the subsequent option of the
> multiplot command. Default is `columnmajor`.
>
>That's confusing: either words in the above are opposite, or "major" does
>not mean "the slower scan in filling". Currently, it works this way:
>"rowmajor" fills columns first, "columnmajor" fills rows first. It should be
>said explicitly e.g.
>

Oh yeah.  Something does seem to be backward.  The behavior I'm seeing 
does look like row major, not column major.

>
> This grid is filled rows first or columns first depending whether
> `columnmajor` or `rowmajor` is given by the subsequent option of the
> multiplot command, respectively.
>
>Or should the keywords be renamed to e.g. "rowsfirst" and "columnsfirst"?
>

Although "rowsfirst" does seem less ambiguous, I think column major and 
row major are fairly well used terminology.  So, maybe stick with that 
terminology and just change the documentation so that it says `rowmajor` 
is the default.  (Octave types out a little diagram in its "help 
subplot" text.)

>And yet another observation:
>If a wrong option is given, e.g.
>       set multiplot layout 3,2 blacolumnmajor
>produces error message:
>    did not expect anythig here
>Firstly, there should be "anything". Secondly, the message is not
>very well descriptive. What about "wrong option" instead?
>

Yeah, not a good comment, because obviously gnuplot does expect that 
something could follow.  "Unrecognized option" or "Invalid option" 
perhaps.  "wrong" sounds too much like it could be a valid keyword, but 
just used out of context.

Dan

Re: multiplot doc spelling errors

[Petr M. <mi...@ph...>]

> Also, I notice in this documentation that
> ?nomultiplot
> is a means to access this text.  Perhaps all the cases of
> ?no<keyword>
> that appear in gnuplot.doc can be moved under the same heading
> ?nomultiplot
> ?noarrow
> etc.

Enclosed is a patch that moves all this "?no" into the section of "What's
new in 4.0" => "3 Other changes and additions". Do you like it?

---
PM

Re: multiplot doc spelling errors

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

Petr Mikulik wrote:

>>Also, I notice in this documentation that
>>?nomultiplot
>>is a means to access this text.  Perhaps all the cases of
>>?no<keyword>
>>that appear in gnuplot.doc can be moved under the same heading
>>?nomultiplot
>>?noarrow
>>etc.
>>    
>>
>
>Enclosed is a patch that moves all this "?no" into the section of "What's
>new in 4.0" => "3 Other changes and additions". Do you like it?
>

Conceptually I like it.  But looking at the code a bit, I see that 
"no<>" is handled not as an individual command (or more accurately, a 
whole bunch of individual commands), but rather is handled in a special way:

    } else if (input_line[token[c_token].start_index] == 'n' &&
           input_line[token[c_token].start_index+1] == 'o') {
    if (interactive)
        int_warn(c_token, "deprecated syntax, use \"unset\"");
    token[c_token].start_index += 2;
    token[c_token].length -= 2;
    c_token--;
    unset_command();

[By the way, the "deprecated syntax" warning gets printed even if the 
associated keyword is not a valid one.  Everyone's OK with that? 
 Putting the warning after the call to "unset_command()" might fix that 
because unset_command() should break out if there is an error.]

This means that even as new keywords get added to gnuplot, say "foo", 
something like "nofoo" will work for "unset foo".  But, that means it is 
difficult for someone to anticipate having to add "nofoo" to the list of 
items in the "gnuplot.doc" file.  In other words, the list

-
+?noarrow
+?noautoscale
+?noborder
+?noclip
+?nocontour
+?nodgrid3d
+?nogrid
+?nohidden3d
+?nohistorysize
+?nokey
+?nolabel
+?nologscale
+?nomouse
+?nomultiplot
+?nomx2tics
+?nomxtics
+?nomy2tics
+?nomytics
+?nomztics
+?nooffsets
+?noparametric
+?nopolar
+?nosurface
+?notimestamp
+?nox2dtics
+?nox2mtics
+?nox2tics
+?nox2zeroaxis
+?noxdtics
+?noxmtics
+?noxtics
+?noxzeroaxis
+?noy2dtics
+?noy2mtics
+?noy2tics
+?noy2zeroaxis
+?noydtics
+?noymtics
+?noytics
+?noyzeroaxis
+?nozdtics
+?nocbdtics
+?nozmtics
+?noztics
+?nocbmtics
+?nocbtics


is always going to be an insufficient list to cover all the uses of 
"no<>".  As an alternative, if you prefer, I've attached a patch with a 
small mod to "help.c" to map any "no<>" to "no deprecated", and then in 
gnuplot.doc I put a "no deprecated to unset" in place of all the 
keywords listed above.  (Change the heading "no deprecated to unset" if 
you like.)

[Of course, with my BTW comment above, the patch I've supplied will 
print out the "no deprecated to unset" help for "help nojunkeroo" and 
such.  A bit hypocritical I guess, but I think that is tolerable.  I 
could easily modify it so that "no" is stripped off the keyword, then a 
FindHelp() is done to see if the keyword exists.  If so, then replace 
the keyword by "no deprecated" and continue through the rest of the 
function.  However, always printing out the deprecation help might be 
preferred.]

... While on the topic about lists becoming outdated.  There is this 
list, which I think is always apt to be overlooked:

    static char GPFAR unsetmess[] =
    "valid unset options:  [] = choose one, {} means optional\n\n\
\t'angles', 'arrow', 'autoscale', 'bar', 'border', 'boxwidth', 'clabel',\n\
\t'clip', 'cntrparam', 'colorbox', 'contour', 'dgrid3d', 'decimalsign',\n\

etc.  I think at some point, a short bit of code to pull these from the 
the list of keywords and automatically format to 80 letters wide would 
be nice.

And, not straying too far off the subject still, there is the case 
statement:

     switch(found_token) {
    case S_ANGLES:
    unset_angles();
    break;
    case S_ARROW:
    unset_arrow();
    break;

which probably could be done with lookup in a table of functions... but 
perhaps that is just a cosmetic thing because case statements often end 
up as table lookup once compiled.

Dan

I've also included a short patch to weed out "unset_multiplot" from the 
unset.c file.  If it is not conditional (i.e., "#if 0") and can be 
reproduced easily if needed at a later date, I'd say just weed it out to 
avoid cruft.