liudr:
IMHO, this should be done: println should instead of calling print then print(0d, 0a), call print then cursor(home), cursor(next line). This way lcd library needs to define cursor(home) to be setcursor(0,current row), and cursor(next line) as setcursor(column,current row+1). Since lcd library is not making use of cursor position, it can't be implemented. Then serial can define cursor(home) as write(od) etc.
It is an interesting idea/concept, but newline processing isn't that simple.
For example, there is also how to handle the display and cursor position
when the characters hit the edge of the line on the display (right side, when using a left to right orientation)
before a newline is sent.
Things like do you wrap and drop down a line when the edge is reached on a line or do you wrap to the beginning
of the same line or do you start dropping the characters.
Then there is what to do on the bottom line. Do you wrap back to the top line or start dropping characters or
do you scroll the existing text on the display and then wrap back to column 0 and erase any characters on the line.
In order to scroll the text up/down on a device like a hd44780,
you have to have a shadow buffer of all the characters on the display and re-write the data "scrolled"
to the display.
In the grand scheme of things, would support for these new cursor functions that Print could use
really be any different than simply using write(0xd) and write(0xa)?
It seems to be inventing a new way of doing the same functionality that could be handled with the existing
0xd and 0xa characters.
(other devices and libraries including other lcd & glcd libraries are handling newlines ok without the need for these new functions)
In order to handle line wrapping of long lines and scrolling I believe it would be too much of a burden
and start to get messy to have to communicate
the display dimensions to the Print class as well as have to configure it for newline, wrapping, and scrolling behaviors.
I think Print is ok as it is.
Print is fairly clean and simple as it lets the lower layer deal with any/all the newline, wrapping, and scrolling issues
of the device.
As a Quick & Dirty ugly but effective hack to prevent println() from being used,
the LiquidCrystal.h header file could add this line after the #include "Print.h"
#define println println_IS_NOT_SUPPORTED
While, it will create a little bit of a strange compiler error about the redefined function
not existing in the LiquidCrystal class, it will prevent the code from compiling.
Depending on the sketch code, the IDE will jump to the line with the println() showing it as an error.
(Often it positions to the wrong line because the IDE is not handling the line numbers correctly when
it converts the .pde/.ino files to .cpp files)
(This seems to have finally been fixed in IDE 1.5)
--- bill