Am 09.10.2014 um 18:51 schrieb Riccardo (Jack) Lucchetti:
On Thu, 9 Oct 2014, Sven Schreiber wrote:
> What I like about this is that it is in principle
> i.e. in the future you could use the same "pidgin" commands to trigger
> some other graphics engine in the background, if somebody wrote the
> necessary bindings.
> OTOH however there is a tradeoff; I think Allin is also right in that he
> doesn't want to reinvent the wheel and thus chose to outsource the
> plotting stuff to gnuplot. The logical implication then is that to
> control plots users need to speak gnuplotish, instead of extending hansl
> to that area.
> Of course you could argue that gnuplot's results are just so great, only
> the syntax bothers you. But is that really the general opinion? I
> somehow doubt that.
I like this approach.
I fully agree that 4 approaches are too many; however, IMO "textplot"
could be scrapped: it's nice to have something that retains the flavour
of 80x25 displays, but that's (as far as I'm concerned) just a
In principle I agree, but just recently I used gretl's ASCII graphics to
send some results in a plain email (without attachment), which was also
nice. But AFAIK gnuplot can also produce ASCII output, so that could be
substituted I guess. (So that would be a feature request for
After all, if you really really want to do
really really complex things, you'd probably want to export your data
and start from scratch with something else. And besides, you can always
use the --input switch.
Again, I agree in principle. OTOH I think many people (including me)
like the inline way of controlling everything from a single script file.
So it was good to be able to supply literal gnuplot commands inline
inside curly braces.
The practical problem with that was that some things didn't work,
because the stuff inside the curly braces was put by gretl in a certain
place/ordering in the resulting command string, which was not the right
place/ordering according to gnuplot syntax. (Sorry I don't remember the
concrete details right now.)
So if somehow this ordering flaw could be addressed, then in theory I
guess you could achieve anything that gnuplot can do, inline in a hansl
script, without auxiliary files.
So that would leave the stripped-dow version of the gnuplot command and
the new "plot" environment.
I'm now thinking, why actually stripping down the gnuplot command? This
would mean to scrap stuff which is working nicely, mostly. Of course the
way that the command is described in the docs could be adjusted in order
to encourage other usage. But stripping down the functionality would
seem to have no real benefit.
And, like you said, this opens up the
possibility of using a different backend in the future. Plplot, for
example, whose output is very cool and has very nice C bindings. But
that's far into the future.
Yes it is.