gnuplot-beta — Developers and beta testers of new gnuplot code

Mouse in x11 interactive terminal

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

By default, all mouseable interactive terminals switch on mouse by default, 
and do it also when driven via pipe (OS/2, Windows, ...). The only exception 
is the X11 terminal when gnuplot runs in pipe. Thus, it is not compatible to 
other defaults.

"help mouse x11" writes:

X11 mouse support is turned on by default if standard input comes from a 
terminal (tty). Mouse support is turned off if standard input does not come 
from a tty, e.g. a pipe. If you want to use mouse support while writing to 
gnuplot from a pipe, the mouse must be turned on *before* starting the x11 
driver, e.g. immediately after startup with the explicit command `set 
mouse`.


Does somebody remember why gnuplot-x11 behaves like that? I think this is a 
relict nowadays. I propose to switch on mouse also for this combination. 
That would make many people happy and gnuplot behaviour compatible.

---
PM

Re: mouse in gnuplot

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

> Any idea why zooming with mouse does not work if I do:
> echo "set mouse; plot sin(x)"  | gnuplot -persist
> ?
> (on linux/x86 - FC4 and FC3)

See
   http://www.gnuplot.info/faq/faq.html#SECTION00076000000000000000

---
PM

Advice in C code

[V. <gae...@no...>]

    Hello all,

    I've been working a bit on the povray terminal (I am very slow
but it has finally made some progress).

    I have a question to which I have not been able to find local advice
on :

    Is the syntax :

    current_color =3D (rgb_color){0, 0, 0};

    Standard and portable. It compiles with gcc 3.3.5 but I do not know
if it is standard C.

    Thank you

--
    Ga=EBl

CVS doesn't build epslatex terminal

[Birger B. <bbr...@cs...>]

Hello List,
I just downloaded the latest CVS and noticed that it does not compile
with the epslatex terminal. I found the problem to be that
term/pslatex.trm is only included by src/term.h when PSLATEX_DRIVER
is defined. In src/term.h it says it is defined in term/post.h but it
is not! Instead it is defined in term/pslatex.trm (in fact it was just
moved there recently) and thus it never gets included unless one
defines PSLATEX_DRIVER himself.

I suppose this is not meant to be this way...

Birger

Re: epslatex, pslatex, and pstex terminals do not exist anymore

[Harald H. <h.h...@tu...>]

On Sat, 16 Jul 2005, Harald Harders wrote:

> On Sat, 16 Jul 2005, Harald Harders wrote:
>
> > Since yesterday's change concerning reorganisation of the
> > POSTSCRIPT_DRIVER conditionals, the terminals pslatex, pstex, and epslatex
> > do not exist anymore. The postscript terminal still works.
> >
> > Could please somebody fix this problem?
> > This patch should help:
>
> Unfortunately, this patch does not work either. Hans-Bernhard, have you
> tested the change at all? At the moment, I try to prepare a more complex
> patch that will fix the problem.

Now, fix #1239398, Reactivate epslatex, pslatex, and pstex terminal, is
available that fixes the problem. Could please somebody apply it?

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: epslatex, pslatex, and pstex terminals do not exist anymore

[Harald H. <h.h...@tu...>]

On Sat, 16 Jul 2005, Harald Harders wrote:

> Since yesterday's change concerning reorganisation of the
> POSTSCRIPT_DRIVER conditionals, the terminals pslatex, pstex, and epslatex
> do not exist anymore. The postscript terminal still works.
>
> Could please somebody fix this problem?
> This patch should help:

Unfortunately, this patch does not work either. Hans-Bernhard, have you
tested the change at all? At the moment, I try to prepare a more complex
patch that will fix the problem.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

epslatex, pslatex, and pstex terminals do not exist anymore

[Harald H. <h.h...@tu...>]

Since yesterday's change concerning reorganisation of the
POSTSCRIPT_DRIVER conditionals, the terminals pslatex, pstex, and epslatex
do not exist anymore. The postscript terminal still works.

Could please somebody fix this problem?
This patch should help:

--- orig/src/term.h     2005-07-16 12:06:54.000000000 +0200
+++ orig2/src/term.h    2005-07-16 13:46:55.000000000 +0200
@@ -396,9 +396,7 @@
 #include "latex.trm"

 /* latex/tex with picture in postscript */
-#ifdef PSLATEX_DRIVER  /* set in post.h */
 #include "pslatex.trm"
-#endif

 /* EEPIC-extended LaTeX driver, for EEPIC users */
 #include "eepic.trm"


Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Drop OSK [was Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]]

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

On Thursday 14 July 2005 03:37 am, Robert Hart wrote:
> 
> There was some investigation about Mircrowave OS9 support (which is
> special cases in some of the data reading code) - I posted a message on
> comp.os.os9 newsgroup. The replies I've got (and my impression from
> reading other posts on the groups is that)
> 
> - if any new version of gnuplot were to be built it would be with gnu
> tools, and therefore special cases probably wouldn't be needed (and
> certainly not for the same functions)
> 
> - nobody is still using gnuplot on that platform (in fact very few
> people are using the platform at all - and mostly for extreme legacy
> stuff - i.e. I can't see them upgrading anyway)
> 
> - the last version of gnuplot to be built was early in the 3.x series
> (possibly 3.1)
> 
> Therefore I think we can drop any #define OSK that are "in the way" -
> and maybe throughout the codebase if somebody feels there is something
> to be gained by that.

OSK is heavily special-cased in gnuplot's built-in readline. This would
clearly be irrelevant if the OSK community has moved to using gnu
libreadline.

The only other places are a malloc() customization in gplt_x11.c and
the previously-discussed variant use of sscanf() in datafile.c.

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

Re: mouse.c (event_reset) bug

[<tim...@en...>]

Ethan Merritt wrote:

>On Friday 15 July 2005 04:15 pm, Timoth=C3=A9e Lecomte wrote:
> =20
>
>>>I am not certain this fix is corrent, since
>>>term->set_cursor() is also called from builtin_cancel_zoom()
>>>
>>>     =20
>>>
>>No, builtin_cancel_zoom returns before calling term->set_cursor()=20
>>because of the following test :
>>
>>    *if* (!setting_zoom_region)
>>	*return* (char *) 0;
>>   =20
>>
>
>For x11 one could imagine that the plot window was closed in the middle
>of doing a zoom. In this case the test you quote above would not stop
>X11_set_cursor from being called, and since closing the plot window may
>have shut down the communication channel we still must test it
>explicitly inside X11_set_cursor.  I do not know if a similar sequence
>of events is possible with your new driver.
> =20
>
I have chosen to just hide the terminal window when the user closes it=20
via the menu or the window manager. Thus, it is still available to=20
answer to such calls.

> =20
>
>>Of course, I can make such a test. And I will. I thought it would be=20
>>easier to fix the calling path ;-)
>>   =20
>>
>
>I understood that.  I am just pointing out that if you truly want
>to protect the calling path, a different fix may be needed.
> =20
>
Ok, I understand. No problem !

Timoth=C3=A9e

Re: mouse.c (event_reset) bug

[<tim...@en...>]

Ethan Merritt wrote:

>On Friday 15 July 2005 03:17 pm, Timoth=C3=A9e Lecomte wrote:
> =20
>
>>While working on my wxwidgets terminal, I've just encountered the=20
>>following problem : typing "set terminal wxt" twice (without any plot=20
>>call between) gives a segmentation fault.
>>   =20
>>
>
>That is indeed a problem, but since existing drivers do not segfault
>on two "set term" command I think this is a something you need to
>fix in your driver.
>=20
> =20
>
> (...)
>
>--- mouse.c	2005-07-16 00:01:58.000000000 +0200
>+++ mouse2.c	2005-07-16 00:02:51.000000000 +0200
>@@ -1782,7 +1782,7 @@
>     modifier_mask =3D 0;
>     button =3D 0;
>     builtin_cancel_zoom(ge);
>-    if (term && term->set_cursor) {
>+    if (term && term->set_cursor && term_initialised) {
> 	term->set_cursor(0, 0, 0);
> 	if (mouse_setting.annotate_zoom_box && term->put_tmptext) {
> 	    term->put_tmptext(1, "");
>
>
>I am not certain this fix is corrent, since
>term->set_cursor() is also called from builtin_cancel_zoom()
>on the line above your new test.
> =20
>
No, builtin_cancel_zoom returns before calling term->set_cursor()=20
because of the following test :

    *if* (!setting_zoom_region)
	*return* (char *) 0;



>Would it not be better to make sure your WXWIDGETS_set_cursor()
>routine does not segfault.  Here is the routine for x11, where you
>can see that if the communication channel is not initialized then
>nothing happens:
>
> =20
>
Of course, I can make such a test. And I will. I thought it would be=20
easier to fix the calling path ;-)

Greetings,

Timoth=C3=A9e

Re: mouse.c (event_reset) bug

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

On Friday 15 July 2005 03:17 pm, Timoth=C3=A9e Lecomte wrote:
> While working on my wxwidgets terminal, I've just encountered the=20
> following problem : typing "set terminal wxt" twice (without any plot=20
> call between) gives a segmentation fault.

That is indeed a problem, but since existing drivers do not segfault
on two "set term" command I think this is a something you need to
fix in your driver.
=20
> Indeed, it calls event_reset to cancel zoombox (in particular) as=20
> explained in a comment in set.c
> event_reset calls term->set_cursor but this fails as the terminal is not=
=20
> initialiased at this stage. I don't think it's a problem from my=20
> terminal, so I am proposing the attached patch to check for=20
> term_initialised.

=2D-- mouse.c	2005-07-16 00:01:58.000000000 +0200
+++ mouse2.c	2005-07-16 00:02:51.000000000 +0200
@@ -1782,7 +1782,7 @@
     modifier_mask =3D 0;
     button =3D 0;
     builtin_cancel_zoom(ge);
=2D    if (term && term->set_cursor) {
+    if (term && term->set_cursor && term_initialised) {
 	term->set_cursor(0, 0, 0);
 	if (mouse_setting.annotate_zoom_box && term->put_tmptext) {
 	    term->put_tmptext(1, "");


I am not certain this fix is corrent, since
term->set_cursor() is also called from builtin_cancel_zoom()
on the line above your new test.

Would it not be better to make sure your WXWIDGETS_set_cursor()
routine does not segfault.  Here is the routine for x11, where you
can see that if the communication channel is not initialized then
nothing happens:

TERM_PUBLIC void
X11_set_cursor(int c, int x, int y)
{
    if (X11_ipc) {
        PRINT3("u%04d%04d%04d\n", c, x, y);
        FFLUSH();
    }
}




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

mouse.c (event_reset) bug

[<tim...@en...>]

Hi !

While working on my wxwidgets terminal, I've just encountered the=20
following problem : typing "set terminal wxt" twice (without any plot=20
call between) gives a segmentation fault.

Indeed, it calls event_reset to cancel zoombox (in particular) as=20
explained in a comment in set.c
event_reset calls term->set_cursor but this fails as the terminal is not=20
initialiased at this stage. I don't think it's a problem from my=20
terminal, so I am proposing the attached patch to check for=20
term_initialised.

I hope this can be included !

Greetings,
Timoth=E9e Lecomte

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

On Friday 15 July 2005 07:22 am, Hans-Bernhard Broeker wrote:
> 
> So yes, at the moment PM3D is currently contributing a major part to 
> breaking the DOS build's back. For now, I have to remove the postscript
> driver to come close to a   buildable DOS 16-bit version.

Sorry, but I just do not see this as being an important issue.
I frankly don't think that support of 16-bit DOS should be a consideration
in gnuplot development.

I refer you again to the article that Robert Hart (no connection
to Lucas Hart that I know of :-) pointed out the other day, which argues
against spending any effort to support minority platforms.  

  http://www.livejournal.com/users/udrepper/7326.html

and subsequent discussion on Slashdot

  http://developers.slashdot.org/article.pl?sid=05/05/30/2233251&from=rss

The guy takes it too far IMHO, since he is focused on minority platforms
within the  already restricted unix-derived world. But the point is even
more apposite when applied to our case.  We should let obsolete platforms
(Amiga, DOS16) and terminals (ggi, NextStep, selanar) die a natural
death and purge them from the development tree.  Not so much because
nobody uses them, but because nobody is implementing the new features
in these code segments.  What is the point of having a NextStep driver
in 4.2 if it doesn't support any of the features added since 3.7?
What is the point of having a ggi driver that requires libraries from
SCO/Caldera which are no longer distributed even by the vendor?

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

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

> The 633K version still doesn't quite work yet.  But there's no way a 
> 704960-byte program can run on DOS.

It can, compiled with a 32bit extender-friendly compiler like emx, djgpp, 
etc.

> So yes, at the moment PM3D is currently contributing a major part to breaking 
> the DOS build's back.
>
>> If I recall correctly, PM3D per se is not a problem even for 16-bit
>> DOS. It's the PostScript driver that is the killer, because its text
>> section contains huge blocks of PostScript prolog string data.
>
> For now, I have to remove the postscript driver to come close to a buildable 
> DOS 16-bit version.  Win16 should be a different story.

Instead of disabling all new features available in gnuplot 4.0, users can 
use gnuplot 3.7, and all is working fine without any additional work.

Why to bother with pure 16bit version?

---
PM

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Hans-Bernhard B. <br...@ph...>]

Ethan A Merritt wrote:

> issue?  Is there reason to believe that the size difference on non-unix
> platforms will be greater that 10%?  

On the platforms I'm concerned about, it will be larger than 10%, simply 
because the program itself will already have to be considerably smaller 
there.  So the figure to keep in mind is the absolute size of the PM3D 
code, not the relative change.  That appears to be 100 kB, for the 
Unix-based case.  16-bit code tends to be smaller, so it won't be quite 
as much on DOS or Win16.  Current status is that enabling PM3D brings 
the DOS16 build (very small term.h) from 633264 bytes to 704960 bytes.
The 633K version still doesn't quite work yet.  But there's no way a 
704960-byte program can run on DOS.  If I turn off essentially *all* 
optional features (string vars, PM3d, image, histograms, ...), I get 
down to 592560 bytes.

So yes, at the moment PM3D is currently contributing a major part to 
breaking the DOS build's back.

> If I recall correctly, PM3D per se is not a problem even for 16-bit
> DOS. It's the PostScript driver that is the killer, because its text
> section contains huge blocks of PostScript prolog string data.

For now, I have to remove the postscript driver to come close to a 
buildable DOS 16-bit version.  Win16 should be a different story.

Re: terminal API: Intent of multiplot suspend/resume?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> You misunderstood me.  I was proposing to replace the separate 
> TERM_TABLE entries with sub-options to term->private() or whatever
> this new API entry would be called.  So existing calls to 
> term->suspend()  would become calls to term->private(SUSPEND).

I'm wildly against this.  The term API is supposed to be "add-only".
Changes to existing calls, and certainly removals of entire entries, are
out of the question.

> ???   The point is that I cannot use them for the purpose of detecting
> such a change *in general*, because they are only called under certain
> conditions.

As I said: the number of conditions in which term->suspend() is called 
could, and possibly should be extended.  There's no really good reason 
why the plot would *have* to be interactive for term->suspend() to ever 
be called.  It may just take some more caution (e.g. those GUI drivers 
that have it trigger a graph window update may want to support 
incremental updates instead of full redraws).

  > Terminal drivers can test for "if (interactive)" on their own.

No, they can't --- the 'interactive' flag is outside the realm of the 
terminal layer, and should remain there.  Two drivers (amiga, post) 
already blundered ahead and referred to this global variable.  That's
a serious no-no.  It's practices like this that have kept gnuplot the 
tangled mess we're still facing.  Such abuse has to be *reduced*, not 
added to.

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

>> PM3D support adds image processing but that is an option in v4.0.

PM3D being a configure option dates to its beginning in 1999, when it was 
just an option to draw colour maps and surfaces (well, the "image 
processing" is not the best term for this).

>> Users who have no need for the image processing features, who do
>> not have graphics hardware to support PM3D graphics, or to whose
>> OS PM3D is not ported can build a v4.0 executable without PM3D
>> support.

PM3D features can be used on any platform -- and if even not natively via 
a screen terminal, then via postscript or png.

"Not having need for pm3d" is not a good excuse for not compiling it in. 
E.g. the fitting module is not used by many people and it's there as well, 
etc.

>> You seem to be taking the position that portability and local
>> configurability of gnuplot are no longer goals,

Yes it is, but pm3d is a functionality of gnuplot, it does not depend on 
external tools, thus it does not need system-specific configure.

> plots with portable color assignments, filled curves, color-coded
> scatter plots, and so on.

This shows that the PM3D has propagated into so many places that that's 
really just the time to remove its #idefs.

>> I believe requiring gnuplot users to include PM3D support is a major 
>> change that may affect portability.

Don't you rather mean that NOT including PM3D decreases portability?

> I would be more impressed by that argument if someone could point
> to a single platform for which inclusion of PM3D  support is problematic.
> Are you agreeing with HBB that a 10% size difference is a make-or-break
> issue?  Is there reason to believe that the size difference on non-unix
> platforms will be greater that 10%?  I encourage someone to run the
> same test builds I did on, say, MSWindows.

I don't think that's worth it -- mainly if GNU C compiler is used.

---
PM

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

On Thursday 14 July 2005 10:47 pm, Lucas Hart wrote:
> > >In particular PM3D is now so integral to many new features that I
> > >think it would make no sense for anyone to upgrade past version 4.0
> > >and *not* include PM3D.  Why go out of our way to support a
> > >combination of options that doesn't make any sense?
>
> Has there been a consensus on such a change in the direction of
> gnuplot development?
>
> From the gnuplot home page "Gnuplot is a portable command-line driven
> interactive data and function plotting utility for ...many platforms
> ... has grown to support many non-interactive uses, including web
> scripting and integration as a plotting engine for third-party
> applications like Octave."

I see no change away from that policy statement.

> PM3D support adds image processing but that is an option in v4.0.

But there the description goes off the rails.  PM3D may have been
originally motivated by image processing, but most/all of the #ifdef PM3D
code segments in gnuplot have absolutely zero to do with image 
processing.

> Users who have no need for the image processing features, who do
> not have graphics hardware to support PM3D graphics, or to whose
> OS PM3D is not ported can build a v4.0 executable without PM3D
> support.

This makes no sense to me (does it really say this on our home page?).
There is no graphics hardware required for PM3D, nor is there an OS
requirement. Zero. None. Nada.  This statement is just utterly confused.

> You seem to be taking the position that portability and local
> configurability of gnuplot are no longer goals, rather that newer
> versions of gnuplot are intended solely for systems capable of being
> used for image processing

Forget this business about image processing. That is a red herring.
That phrase appears nowhere in the gnuplot documentation, and should
not appear on the web site either. 

In fact the portability and generality of gnuplot scripting is very
much improved by the PM3D code. I have never used gnuplot for image
processing, but my web scripts use the PM3D code daily for generating
plots with portable color assignments, filled curves, color-coded
scatter plots, and so on.

> While it is an additional burden on developers to code and test
> w/ and w/o PM3D support, and building w/o PM3D support on Linux
> platforms may have little impact on resources, I believe requiring
> gnuplot users to include PM3D support is a major change that may
> affect portability.

I would be more impressed by that argument if someone could point
to a single platform for which inclusion of PM3D  support is problematic.  
Are you agreeing with HBB that a 10% size difference is a make-or-break
issue?  Is there reason to believe that the size difference on non-unix
platforms will be greater that 10%?  I encourage someone to run the
same test builds I did on, say, MSWindows.

If I recall correctly, PM3D per se is not a problem even for 16-bit
DOS. It's the PostScript driver that is the killer, because its text
section contains huge blocks of PostScript prolog string data.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[<ha...@on...>]

On Wed, Jul 13, 2005 at 06:14:02PM +0200, Petr Mikulik wrote:
> >
> >On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote:
> >>
> >>I still haven't fully given up revitalizing the 16-bit
> >>builds yet (I've got DOS16 to link with OW, a third-party linker and
> >>some serious modifications...). These 10 percent of extra load could
> >>easily kill those.
> >
> >I think that effort would be a total and utter waste of your time.
> >Anyone runinng 16-bit DOS can just live with version 3.7
> 
> I think so too. Those old PC's are not used for image processing anyway, 
> so they have no reason to switch to gnuplot >= 4.0.
> 
...
> 
> >In particular PM3D is now so integral to many new features that I
> >think it would make no sense for anyone to upgrade past version 4.0
> >and *not* include PM3D.  Why go out of our way to support a
> >combination of options that doesn't make any sense?
> >
> >So yes, I think the PM3D code should be made unconditional.
> 
> I will do this change within one week if there is no really strong 
> objection.
> 

Has there been a consensus on such a change in the direction of 
gnuplot development?

From the gnuplot home page "Gnuplot is a portable command-line driven 
interactive data and function plotting utility for ...many platforms 
... has grown to support many non-interactive uses, including web 
scripting and integration as a plotting engine for third-party 
applications like Octave."

PM3D support adds image processing but that is an option in v4.0.
Users who have no need for the image processing features, who do 
not have graphics hardware to support PM3D graphics, or to whose 
OS PM3D is not ported can build a v4.0 executable without PM3D 
support.

You seem to be taking the position that portability and local 
configurability of gnuplot are no longer goals, rather that newer 
versions of gnuplot are intended solely for systems capable of being 
used for image processing and that, consequently, other improvements 
which might be of value for data and function plotting on older 
platforms (e.g., expanded features for labels, keys, strings, and 
the postscript terminal, font selection, the histogram style, multi-plot 
layout, etc.) will not be made available to users unless they can and
do build with PM3D support.

While it is an additional burden on developers to code and test
w/ and w/o PM3D support, and building w/o PM3D support on Linux 
platforms may have little impact on resources, I believe requiring
gnuplot users to include PM3D support is a major change that may 
affect portability.
 
Since PM3D is still conditional in the cvs build, I would advocate not
removing the build option until after a v4.1 release so that the other 
new features may be made available to a broader user base and at which
time some user feedback can be obtained about the impact of requiring 
PM3D on other platforms.


- Lucas Hart
  Oregon State University
  Corvallis, Oregon USA

mouse in gnuplot

[Dmitri A. S. <dm...@un...>]

Any idea why zooming with mouse does not work if I do:

echo "set mouse; plot sin(x)"  | gnuplot -persist

?
(on linux/x86 - FC4 and FC3)

The problem came about when I was trying to figure out why zooming
with mouse does not work on octave on MacOSX (with X11 term).
There is no problem with that on linux/x86 though...

I tried both gnuplot-4 and a recent cvs snapshot.

Sincerely,

Dmitri.
-- 

Re: terminal API: Intent of multiplot suspend/resume?

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

On Thursday 14 July 2005 12:30 pm, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Thursday 14 July 2005 11:49 am, Hans-Bernhard Broeker wrote:
> 
> >>* Removing suspend()/resume() completely would be a Very Bad Idea[TM].
> 
> > Removing them would save about 400 bytes of permanent storage in
> > TERM_TABLE.  Other than that it's all cosmetic.
> 
> It would also render 5 more-or-less independent terminal drivers 
> unusable for interactive multi-plotting.  That's what would make it bad.

You misunderstood me.  I was proposing to replace the separate 
TERM_TABLE entries with sub-options to term->private() or whatever
this new API entry would be called.  So existing calls to 
term->suspend()  would become calls to term->private(SUSPEND).

> > The cause of my confusion was the implication in the existing 
> > documentation that these routines could be used to detect the
> > change between one multiplot plot and the next.  They cannot.
> 
> Yet they are.  See the X11, OS/2 PM, Windows, mac and aquaterm drivers.

???   The point is that I cannot use them for the purpose of detecting
such a change *in general*, because they are only called under certain
conditions.
 
> But if we do add a "term->next_multiplot()" call or similar, then yes, 
> these should probably be modified to move that functionality to the new 
> call.  

Exactly.  Except that it should be folded into a more generic API.

> For good measure, such a call should also carry the current  
> "interactive" state as an argument, so the driver can decide whether to 
> trigger a replot or not.

Terminal drivers can test for "if (interactive)" on their own.
They don't need to have it passed to them as a separate parameter.


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

Re: terminal API: Intent of multiplot suspend/resume?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> On Thursday 14 July 2005 11:49 am, Hans-Bernhard Broeker wrote:

>>* Removing suspend()/resume() completely would be a Very Bad Idea[TM].

> Removing them would save about 400 bytes of permanent storage in
> TERM_TABLE.  Other than that it's all cosmetic.

It would also render 5 more-or-less independent terminal drivers 
unusable for interactive multi-plotting.  That's what would make it bad.

> The cause of my confusion was the implication in the existing 
> documentation that these routines could be used to detect the
> change between one multiplot plot and the next.  They cannot.

Yet they are.  See the X11, OS/2 PM, Windows, mac and aquaterm drivers.

But if we do add a "term->next_multiplot()" call or similar, then yes, 
these should probably be modified to move that functionality to the new 
call.  For good measure, such a call should also carry the current 
"interactive" state as an argument, so the driver can decide whether to 
trigger a replot or not.

Re: terminal API: Intent of multiplot suspend/resume?

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

On Thursday 14 July 2005 11:49 am, Hans-Bernhard Broeker wrote:
> 
> So, let's see what my conclusions would be so far:
> 
> * This is not a particularly urgent issue.

Agreed.

> * Removing suspend()/resume() completely would be a Very Bad Idea[TM].

Removing them would save about 400 bytes of permanent storage in
TERM_TABLE.  Other than that it's all cosmetic.

> * suspend()/resume() could help more if they were called in more cases, 
> but probably should not be called in non-interactive mode to avoid 
> excessive redraws.  Benefits could include drivers that want to know 
> which graphical elements belong to which plot, for grouping purposes. 

I am perfectly happy to leave suspend/resume as they are.
The cause of my confusion was the implication in the existing 
documentation that these routines could be used to detect the
change between one multiplot plot and the next.  They cannot.
So I will modify term/README to make it clearer that they 
are only relevant to interactive plots.

This whole line of inquiry started because I was trying to
minimize or eliminate the need for a new terminal API function
to implement Harald Harders clever treatment of front/back text
in epslatex.trm.  I already have a working version (posted to
SourceForge) that makes explicit calls between multiplot
segments. I was hoping to do even better by using suspend/resume
instead, but it doesn't work.

End of story, I think, other than clarifying the text in 
term/README



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

Re: terminal API: Intent of multiplot suspend/resume?

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

On Thursday 14 July 2005 11:24 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Thursday 14 July 2005 10:09 am, Dave Denholm wrote:
> > 
> >>I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably
> >>referring to issuing a prompt during multiplot at all.
> 
> > Furthermore, the code segment that tests it can never be reached.
> 
> For that I'd like to see proof.

My bad.  

There is in fact one way to the code path, which is piping to gnuplot
with no arguments on the command line, and no load command involved:
	gnuplot < somefile

This is distinct from 3 other cases which one might expect to behave
similarly:
	gnuplot somefile
	echo "load somefile" | gnuplot
	gnuplot
gnuplot> load "somefile"






Here is the analysis:

term_check_multiplot_ok() has only one caller:   com_line()

com_line() occurs in only 4 places. Here they are:

misc.c (load_file):

    } else if (fp == stdin) {
        /* DBT 10-6-98  go interactive if "-" named as load file */
        interactive = TRUE;
        while (!com_line());

plot.c (main):

618:
        if (strcmp(*argv, "-") == 0) {
                /* DBT 10-7-98  go interactive if "-" on command line */
                interactive = TRUE;
                /* will this work on all platforms? */
                while (!com_line());

631:
#ifdef _Windows
        if (noend) {
            interactive = TRUE;
            while (!com_line());
        }
#endif
    } else {
        /* take commands from stdin */
        while (!com_line());
    }

That last "else" condition corresponds to (argc < 1), and is the only
site at which interactive is not guaranteed to be TRUE.






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

Re: terminal API: Intent of multiplot suspend/resume?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> Yes.  But term_check_multiplot_ok()  itself is only called in
> interactive mode.  

Ooops, should have checked that.

Well, given the new evidence, either its interface is quite completely 
wrong, or it's not used in the way.

So, let's see what my conclusions would be so far:

* This is not a particularly urgent issue.

* Removing suspend()/resume() completely would be a Very Bad Idea[TM].

* suspend()/resume() could help more if they were called in more cases, 
but probably should not be called in non-interactive mode to avoid 
excessive redraws.  Benefits could include drivers that want to know 
which graphical elements belong to which plot, for grouping purposes. 
SVG, e.g., could usefully open a new group for each plot of a multiplot 
page, for more meaningful manipulation by third-party tools.

* The above may necessitate a factorization of what suspend() does into 
two jobs: informing the driver that a new plot in a multiplot has 
started, and telling the driver that the interactive user now needs the
text interface, not the graphics, to be shown.

* TERM_CAN_MULTIPLOT shouldn't decide on whether or not term->suspend() 
gets called at all.  It may be superfluous, i.e. replacable by a test 
that term->suspend() and term->resume() exist.

* TERM_CANNOT_MULTIPLOT has to be tested earlier than it is, possibly 
from inside "set multiplot" itself.

* we may need a way to have redirected stdin sources decide for 
themselves whether they want to act like interactive or not, as far as 
multiplot is regarded --- the command source could itself be 
interactive, or it could just be a script generator, and currently 
gnuplot has no way of distinguishing between the two.