ietf-822
[Top] [All Lists]

Re: draft-gellens-format-00

1998-08-14 08:58:15
                "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 
 


<Prev in Thread] Current Thread [Next in Thread>