* consider trailing white space as fair game
for arbitrary appendage or deletion;
it can't be seen, pretend it simply isn't there
It'll make input parser of applications quite complex and is good for
nothing.
I'm not sure how to respond to this. To me, it's not only
NOT "good for nothing", but one of the more important points.
Please note that I did NOT say "strip trailing white space".
What I said was "don't presume that it won't be stripped or added".
There's a BIG difference.
How does it make input parsing "quite complex"? Sure, it's
more work than before, but I argue that the added effort is 1: small
and 2: worth it. Look ... we're already parsing on white space (or
SPACE 0x20) anyway. How hard can it be to continue? How difficult
is it to "parse one more blank delimited token and discard it"?
Better wording would be "parse as if there'd be one more blank
delimited token". This is trivial.
* for the sake of those of us with XTs or VT100s,
keep lines shorter than 80 columns, maybe <76
Perhaps, you aren't assuming proportional spacing.
No. Plain text never looks right with proportional spacing.
How wide is a column?
I don't really care. The less-than-80 recommendation
isn't going to cover everyone. Surely someone out there is running
a TRS-80 with a 64-column screen. (hopefully they don't inhale)
If you really want mail to look nice on *anyone's* screen,
then you've got to send it as "enriched" or full-blown SGML and let
the receiving software format it. But how many people take that much
time when composing e-mail?
Masataka Ohta
--
Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems