Re: replotting in-line data and autoscaling

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> I have a strong aversion to complicated last-minute changes before a
> release. If there's some stupid error in the logic because of log
> scaling that might have a trivial fix. But re-doing the way autoscale
> + replot works sounds like a major change that I'd want to have tested
> in the development version for a while before it went into a minor
> level release.

OK. Yes. Let's then talk about it separated from this release.


> I agree this is undesirable, but I don't see an immediate fix.
> There are at least a couple of work-arounds however
>
> 1) Don't replot in-line data.  That didn't use to be possible at
>    all and as you have found the change to allow it was imperfect.
>    Put the data in a datablock instead.
>
> 2) Use writeback/restore:
> 	set xrange [*:*] writeback
> 	plot '-'
> 	...
> 	set xrange restore
> 	replot

Neither of these work for me. 99% of my (quite heavy) gnuplot usage is
via this frontend: https://github.com/dkogan/feedgnuplot

It'd be great if we supported this sort of interface natively, but
that's a separate (and bigger) conversation. Inline data is a core
assumption of this tool. And since the window manager is doing the
replotting, I'm not explicitly sending the "replot" command, so I can't
explicitly ask gnuplot to save/restore the writeback.

The earlier discussion was this:

  https://sourceforge.net/p/gnuplot/bugs/1947/

The suggestion was:

  when plotting:
    if( we have only inline data)
    {
      save writeback
    }

  when replotting:
    if( we have only inline data &&
        current plot ranges are those
        computed from the autoranging )
    {
      restore writeback
    }

This assumes the data doesn't change for the replot, which is true in
the case of inline data. This actually makes replotting inline data is
easier than data in a file.

Do you see downsides here?

Thanks.