Re: Quick refresh [was: q for quit in plot windows]

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

The following is confusing to me:

" The `volatile` keyword indicates that the contents of the data file may be
 different if the file is re-read.  This tells the program to use `refresh`
 rather than `replot` commands whenever possible.  See `refresh`."

I assume "tells the program" means "tells gnuplot".  But beyond that, the interpretation of this is more left to the user.  OK, "volatile" is clear.  But for one user it may be desired that the volatile files be reread with every new "replot", for another user it may be desired that the volatile files not be reread.  In other words "volatile" is an accurate word, but implication is somewhat ambiguous.

The other thing I don't like is the "whenever possible".  I've been trying to make the point that unless there is precise behavior for this feature the "whenever possible" is going to make the user or programmer give up in futility because he or she won't know when datafiles are actually reread.  "Not when log/unlog via mouse or set", "not when there are splines", "not for this condition", etc.  And there is no documentation about any of this.  It's a guessing game.

I'd say drop the "volatile" keyword.  Then two methods are acceptable.  One, there are two commands "replot/refresh" in which "replot" *always* rereads files and "refresh" *always* retrieves the data from memory.  That way there is no ambiguity and any operation is left to the user's intention.  Two, a mode option for replot say

set replot {reread:noreread}

Again, in "reread" mode "replot" always behaves one way.  In "noreread" mode "replot" always behaves another way.

Then also make the definition that the mouse zoom/unzoom and mouse log/unlog always uses the "refresh" method and never rereads data files.

As for the patch, evaluating it makes me more stalwart on the notion that "refresh" data has to be fed into the system near the start of "get_data()" and fed through the whole system for reprocessing.  There can't be an ancillary hunk of code that duplicates some operation that is within "get_data()" and then circumvent other aspects of "get_data()" going directly to "eval_plots()".  That's difficult to follow from a programmer's perspective and some day a new programmer will alter something in one place and not realize something must be changed in another place.

Again, I want to point out the factual content of the v's and j's that come from df_readline().  There are only MAXDATACOLS, which is seven (plus 1 for j).  That is the equivalent of a "point".  I don't see the storage of the v's and j's being any worse than storing the points.  In fact, after knowing the maximum j, we can narrow the width of any records of the v's and j's to save space.  Furthermore, in some and maybe all circumstances the "points" array could be discarded after the plot is done if we retain the v's and j's.  The mouse zoom/unzoom, mouse log/unlog, mouse rotation in 3D are all something that could be redone with the "refresh" mode of operation.  Tapping into df_readline seems the way to go, to me.

As for the "strings", those are already saved in the plot structure so they are readily available.  There is a little problem in the sense that cp->labels storage keeps track of a pointer to an element of cp->points.  Would have to figure out something there.  Could tag the label not with the ->point but with the v/j combo and feed that too back through the system from the point of df_readline.

Dan