[========================================================================]

[========= List of things to be done.  Plans, ideas, whatever... ========]

[========================================================================]

COMMANDS:

=========

DOCUMENTATION:

==============

 -- Improve the documentation on fonts

 -- More figures in the manual

 -- We no longer have a working build path for HTML documentation.

    Is there a suitable replacement?

PLATFORMS:

==========

 -- We've seen a proof-of-principle build of gnuplot into javascript

    running in a browser.  If the tool chain is simple enough, we could

    make this a build target for autoconf/make.

 -- autoconf handling of TBOOLEAN on Solaris also remains problematic.

    The definition apparently needs to be different for C and C++.

GNUPLOT TOOLS LIBRARY:

======================

Make a library (e.g. usr/local/gnuplot/scripts/, .../gnuplot/bin) of 

(a) gnuplot scripts, and (b) shell scripts relevant for gnuplot:

-- enclose script "gpsavediff" that diff's output of gnuplot's "save" command 

and default setup after "reset" 

INSTALLATION --- LINUX:

=======================

-- the installation paths for TeX-related files are a mess

[========================================================================]

[========================================================================]

[========================================================================]

Note: use

	www.sourceforge.net/projects/gnuplot

=> "Feature request" for feature requests.

Projects, in no particular order:

- break it into four layers:

  : low level graphics  (some of term.c)

  : plotting code, reading the setshow.h global variables

  : parsing code - read a string, and parse and execute it

  : front end, interact with terminal / gui

  basically, gplotlib is layer 2, and the traditional gnuplot is

  layer 4, which is little more than a small client of layer 3.

  Terminal option lines are table driven,

  so that even though the options are defined by layer 1, the

  actual parsing is implemented in level 3

Lars' list

- provide library of replacement functions instead of stdfn.c

- completely rewrite the parser. Use yacc/bison if possible.

- maybe rewrite the scanner in lex? The benefits are not so obvious,

  because the current scanner is extremely simple. This is probably

  only worthwhile if the parser is rewritten at the same time.

- maybe use PD hash code for table-lookup (SNIPPETS code). Tables for

  builtin and user functions, variables, commands. What else? aliases

- standardise float/double comparisons around the suggestion in the

  comp.lang.c FAQ (What's a good way to check for "close enough"

  floating-point equality?) and symbolic constants from standard header files.

  LOADS of errors throughout the code, especially in graphics.c

- autogenerate term.h from config file in text format and/or configure?

- add more maintainer checks (eg. file permissions)

- better documentation format; get rid of the doc2xxx utils

  [SGML. SGML. SGML]

- tilde and variable expansion to be done by 

  gp_fopen() - to be implemented

HBB:

[Optional:] See if 16-bit compilations can be made to work again.

Ethan's List (2016):

- rewrite javascript support files for the canvas terminal to use

  browser's font support.  Maintain more per-plot context, e.g. zoom state.

- isosurfaces (3D contour of 4D data)

- support mousing in multiplot output

- add additional tic levels, possibly to appear only when zoomed

- configuration/build options to create

	javascript/emscripten executable

	qt-based support for pdf, svg, png, etc (Lodewick patches)

	configure option for a qt-only build (no cairo, no x11, no wxt)

- better tracking of wrapped input lines by the builtin readline code

- 64-bit integer arithmetic

- Remove obsolete files.  But are they truly obsolete?

   term/pc.trm config/makefile.emx