Re: x11.trm terminal options

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

Ethan Merritt wrote:

>On Friday 24 October 2003 12:06, Daniel J Sebald wrote:
>  
>
>>I've looked at the code in term.c regarding opening the file.
>>It looks like the terminal initialization is very safely done with
>>appropriate checks of a variable "term_initialised".  I'm
>>wondering if the actual "fopen()" can't be held off until the
>>function "term_start_plot()".
>>    
>>
>
>Apparently you are not the first one to think so.  The comment
>in term_init (term.c line 406) reads:
>        /* this is nasty - we cannot just term_set_output(outstr)
>         * since term_set_output will first free outstr and we
>         * end up with an invalid pointer. I think I would
>         * prefer to defer opening output file until first plot.
>         */
>

Well, I'm going to leave what to do (if anything) up to you.
The end of this comment, however... isn't "term_start_plot()"
called upon first plot?


>>and in graph3d.c at the start of the "do_plot3d()" routine is
>>
>>    term_start_plot();
>>[Why there isn't a term_init() there also, I don't know.]
>>    
>>
>
>The first thing term_start_plot() does is call term_init().
>So it isn't really necessary in graphics.c at all.
>

Ah, I see.

>>So, it would mean keeping track of the output file name using
>>a character pointer and realloc() and keeping track of the
>>binary/ascii file type.  In term_start_plot(), check if the file
>>name is non-NULL, and if so open the file and free()
>>the memory for the name and set the pointer back to NULL.
>>
>>Does it seem like that would work?
>>    
>>
>
>It could be made to work, but I see several problems.  
>
>The first is that if the output file is illegal it makes far more sense
>to get that error message immediately from the 'set output' command.
>If you defer trying to open the file until later, the error message
>becomes decoupled from the command that caused it.
>

I agree, but I'm not sure that is a major transgression.
If Gnuplot were to instead display a message at the
time of attempted plotting "can't open <filename>", that
is just as good I think.  Say for example there is an
existing file of the name specified but it is write protected.
The user then deletes the file from the OS.  They wouldn't
need to retype 'set output "XYZ"', s/he could just reissue
the plot command.

>Also, remember that some terminal types can put multiple plots
>into a single file, while others cannot.  I would have
>to delve into the code to see if moving the file open to 
>term_start_plot() would trip over that difference or not.
>

I think the closing of the file would remain exactly the
way it is.  When "set output" is called it should be closed.
No changes there.

The strategy I would argue for in "term_start_plot()" is if
there is a valid output file string then attempt opening.
If there is a valid output string and gpoutfile is currently
valid, close that gpoutfile before attempting to open.
Only when the open is successful should gpoutfile
be set and the string cleared.  If not successful at
opening then do not clear the file name.  That way if
the user tries to plot time and again, the same message of
"can't open XYZ" will appear.

If you think the behavior above is preferred, then I would
say remove any opening of a file from set_term_output()
and things would naturally fall into place.  In other words,
the only thing that set_term_output() can do is modify the
file output string or close an open file.  (It should always
close an open file, even if the file name is the same as
the file name that was given previously.)

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/