"We reject kings, presidents, and voting.
We believe in rough concensus and running code."
-- Dave Clark 1992
Ian was trying to ensure that certain essentials were kept
in the proposal, seeing that it has survived beyond a "kill it"
concensus. I haven't followed as closely as I should, but think
the idea of yet-more-dependence on white space is flawed.
Here's what I said ...
---------- Forwarded message ----------
Date: Fri, 14 Aug 1998 10:03:47 -0500 (CDT)
From: Rick Troth <troth(_at_)casita(_dot_)houston(_dot_)tx(_dot_)us>
To: Ian Bell <ianbell(_at_)turnpike(_dot_)com>
Subject: Re: draft-gellens-format-00
I've been trying for several years to stamp out
dependence on certain characteristics of white space
because they consistently break things.
It has been said (and this may be just industry legend)
that when the original author of 'make' had gone home
and gotten a decent night's sleep, he was aghast at the
realization of what he had done. But it was too late,
make was "out the door" and everyone loved it so much
that there was no changing it. So 'make' to this day
has an annoying dependence on <TAB> -vs- <SPACE>.
I would argue that
+ any mixture of TABs and SPACEs
should be treated as a single instance
of white space
+ leading white space is significant
and should by all means be preserved
+ trailing white space is not significant
and should neither be required nor prohibitted
(that is, programs should not care
whether it's there or not)
This is NOT TO SAY that any program should make adjustments
to a data stream it carries from source to target, only that we
should not build dependencies on trailing white space, the kind of
characters (TAB or SPACE), or the number of characters in a single run.
The world changes, and people try to get machines
to do things that they couldn't do before. I fully expect more
use of character recognition, so that documents will get scanned
from paper. In that scenario, leading white space *might* survive,
trailing white space will probably be lost, and intermediate white
space will be hard to quantify as anything more than "just a blank".
Even today, this behavior is seen in cut-n-paste operations.
I hope both you and QualComm will reconsider.
--
Rick Troth at La Casita, Houston, Texas, USA