On Tue, 21 Oct 2003, Petr Mikulik wrote:
> > *) organize the set/show/save/unset/reset implementations by variable, not
> > by command, i.e. the set, show, save, unset and reset (default status)
> > for a given setting should all be in *one* place, not scattered over
> > 4 files (set.c,show.c,unset.c,misc.c). This would make things a
> > lot more OO-ish.
> That'll be a long file then.
No, it won't --- because it'll still be split up into several files, but
along different lines.
> Currently, one has to edit all the 3 files simultaneously.
Exactly, and that's a pain in the lower back we don't need. The plan is
to have all code handling a given setting in *one* place. Be that the
module that implements the effect of that setting, too (pm3d.c for 'set
pm3d', hidden3d.c for 'set hidden3d', etc.), or a special user interface
module for an existing core functionality module (e.g. a setaxis.c to go
> > *) Add a new method, or a flag to the 'save-variable' method of each
> > setting, so it saves only the state different from the default.
> Would that mean most variables need to have this_variable_default_value =
Yes. But you need that info for the 'reset' command, anyway, so it's not
exactly a new requirement.
> Another method of the "diff" save would be to write the output into an array
> of strings, then the same for invoking internally "reset", and write out
> only diff's, and finally re-read internally the status before reset.
Overly complicated. If at all, create an in-memory dump of all settings
immediately after start-up initialization (before reading ~/.gnuplotrc,
that is), and keep that dump around for the whole session.
The sprintf() vs. fprintf() could be relayed to a common s_or_f_printf()
utility routine to be used by all save_foo() functions --- but we'ld
then need vs[n]printf() and vfprintf() on all platforms ;-(
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.