Re: Why docs/term.h ???

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 01 June 2004 09:38 am, Hans-Bernhard Broeker wrote:
>
> No.  This should apply to *all* editions of the documentation integrated
> with the program itself.  In a nutshell: if you type 'help pdf' in your
> gnuplot, it should display the help chunk from term/pdf.trm if and only
> if 'set term pdf', typed at that same prompt, turns on the pdf terminal.
> E.g. only if the PDF terminal was actually built into the program.

What is so bad about giving complete help even if your local version
is incomplete?  If nothing else, it allows the user to think "That looks
nice, I should rebuild gnuplot to include support for PDF".

To pick a random parallel case from the standard linux man page
set, if I type "man sched_setscheduler"
it tells about a bunch of commands to control what CPU my jobs
run on, whether or not I actually *have* more than one CPU.

Similarly if you type "man gcc" you will get compiler options
for architectures you don't have, and "man groff" will describe
options for fancy type-setting devices you don't have.

What I do think might help is if the error message from 
'set term <whatever>' were a bit more informative.
E.g.:

gnuplot> set term foo
	unknown or ambiguous terminal type; type just 'set terminal' for a list
gnuplot> set term pdf
	support for the pdf terminal was not built into your local copy of gnuplot

In fact I would prefer that all conditionally compiled options
produce this sort of error message:

gnuplot> set pm3d
	support for pm3d mode was not built into your local copy of gnuplot 

and so on.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195