09-Mar-2014 Update on version 5 progress

[sfeam <sf...@us...>]

I made a list of proposed targets for version 5 based on recent discussion.
Let me know if I missed any.

The first column indicates current status (09-Mar-2014)
* = complete
+ = preliminary version
- = proposed

Already in CVS
================================================================
* Default to enhanced text mode
* Support for an arbitrary number of axes
+ new "fit" code (in progress)

Target for release candidate 5.0.rc1
================================================================
+ Bold/Italic markup in enhanced text mode (in progress)
- Change the default color sequence, if only so that users know
  this is possible to customize
- Smarter auto-layout of multiplots (e.g. patch #611)
- bit-shift operators  C = A << n    C = A >> n

Target for release 5.0, may be incomplete in rc1
================================================================
- separate control of line property descibing the dot-dash pattern
  e.g. set linetype N dashtype 3 linecolor rgb "blue" 
+ confirm consistency of first N point types across all terminals
  N is I think currently 8.  Increase to 12 or 16?

Unrealistic for version 5; Defer to version 6
================================================================
- multi-language support layer (Patchset #436)
- refactor main data input loop in graphics.c / datafile.c
- refactor log-scale code (store original data, scale during output)

Needs more discussion
================================================================
- Jon Gjengset mentioned a problem with image mode that I am not
  familiar with and doesn't seem to have a Bug Tracker entry.
  "Visible pixel grid has a scan line longer than previous scan lines"
  Is this just a bug, or is there something more fundamental that
  might change the image syntax or handling?
- Should we switch to 64-bit integers everywhere?
  I really don't know how much work this would be.
  This would have the side effect of solving problems with storing
  32-bit ARGB color values in an int.
- Should use of ARGB colors require a new keyword?
  e.g. linecolor {rgb 0xRRGGBB | rgba 0xAARRGGBB}
  My personal opinion is no, but Tait has argued yes.
  More opinions please?
- Do we need additional explicit type-conversion operators?
  e.g.  A=5; string(A)   yields "5"

Feature Request (doesn't need to be coordinated with version 5)
================================================================
- various key options (#183, #297, #339, multiple keys) 
- arrays
- combining data from multiple files into single using spec
- error reports should indicate original source line prior to
  merging continuation lines