Method one (long lines) would be worse than the current situation. I
imagine that once decent richtext editors exist, people will want to
save richtext in files, without transfer encodings, but occasionally
look at these files with simpler tools. Although most editors fold
lines, the fact that a long paragraph *has* to be represented as long
line makes this unworkable -- when a folded long line doesn't fit on
the whole screen even Emacs is very uncomfortable.
I have no objections against method two, although I wonder (and have
always wondered) why there have to be separate conventions for
newlines and for paragraphs, considering that most WYSIWYG tools don't
make or need this distinction. All wordprocessors I know on the Mac
(from MacWrite to MS-Word and Write Now) and also FrameMaker on UNIX
let the user use the RETURN key to start a new paragraph, and also use
the RETURN character to delineate paragraphs when converting to/from
plain ASCII text -- with your method two (double RETURN separates
paragraphs, single RETURN is equivalent to whitespace) as an
alternative option in some cases. Maybe this another Andrew-ism that
has accidentally crept into the definition of richtext?
Regarding procedural matters, I prefer to have a working richtext
standard somewhat later, perhaps in a separate RFC, over a broken
standard version now. (The same argument has successfully been used
to move certain other features, however deemed necessary, out of the
current RFC because their definition was deemed immature.) More
experimentation with richtext is needed!
--Guido van Rossum, CWI, Amsterdam <guido(_at_)cwi(_dot_)nl>
"Is it a bird? No! Is it a plane? No! It's bicycle repair man!"