Guys,
keep in mind that the LiquidCrystal library that ships with Arduino today is pretty much stateless.
It does not track any LCD state information like cursor position, memory addresses, scroll modes, etc...
i.e. when you set a cursor position using setCursor() it sends a command to the LCD
to set the memory address and that is it.
Yes it does a quick sanity check on the values, but
it does not keep track of the cursor position, nor any subsequent internal address changes
when future writes are done.
Keeping track of the cursor position inside the LCD is not terribly difficult but the code to do that currently
isn't there and isn't as easy as it would first seem.
To track things for line wrapping takes more than just knowing the geometry.
You also have to keep and track state information for things the left-to-right vs right-to-left addressing.
It also conflicts with the auto scroll modes, so that will potentially drag in the need for some other
new API calls to deal with that.
In my view, these libraries should be very small and simple and limited to unique
hardware functionality.
Any other functionality like reading strings or parsing strings should not be done
in a hardware library.
That type of functionality should be handled by an upper layer since that functionality
is not unique to the hardware.
With respect to using ifdefs, issues with the Arduino IDE
build methodology quickly arise. Library files are built separately from the sketch.
So that means that a sketch cannot set defines to control conditional compilation
of the library within the source code of the sketch.
Also the way the IDE works, the IDE does not have a mechanism to set defines for a sketch.
A library can have a separate configuration header file down its source directory which works
for controlling conditional compilation options but
then the defines, and hence conditional compilation, is global since
it will set the conditional values for all sketches.
--- bill