Here's a follow-up to
http://lists.wfu.edu/pipermail/gretl-devel/2017-December/008296.html
et seq.
Some package-writers (and maybe others) have written hansl code to
generate custom plots that are difficult or impossible to obtain
via the built-in "gnuplot" and "plot" commands.
Gretl can _display_ any such plot provided the generated gnuplot
script is valid, but offering GUI editing (e.g. via right-click on a
plot window) is trickier. We can offer the editing facility -- with
a reasonable chance that this doesn't reduce the plot to rubble --
only if gretl "understands what's going on" in the plot (that is, if
we're able to parse enough information out of the plot commands to
make sense of it).
There's no way that gretl is going to incorporate a fully-fledged
gnuplot parser but some of my recent changes make the parsing
somewhat more flexible, hence increasing the chances that a custom
plot can be handled in the GUI plot editor. So I'd like to invite
authors of custom plotting code to try this out: Is your custom plot
now (nominally) editable? (That is, does the "Edit" option appear on
right-click?) And if so, does it actually work or does making
changes destroy the plot?
For anyone interested in pursuing this, here are a few pointers.
1) Take a look at the gretl-generated gnuplot code for a variety of
plot types, to get a sense of the "house style" which is likely to
be supported.
2) If C doesn't scare you away, maybe look at some of the functions
in gui2/gpt_control.c, in particular parse_gp_line_line() and
parse_gp_set_line(). In such functions you see gretl trying to make
sense of core gnuplot commands -- that should give you a more
precise idea of what formulations we can handle (and by elimination,
what we're not ready to handle).
3) If your plot contains formulations that gretl cannot handle
natively, try protecting them by placing them within the following
two special comment lines in the gnuplot file:
# start literal lines
...
# end literal lines
That way gretl will know not to mess with them.
Allin