delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/07/09/00:15:20

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 8 Jul 2004 21:14:22 -0700 (PDT)
From: Eduardo Chappa <chappa AT math DOT washington DOT edu>
To: cygwin AT cygwin DOT com
Subject: Re: Wrapping long lines (Was Re: FAQ update suggestion for "I'm having basic problems with find. Why?")
In-Reply-To: <40EDF623.AF728A26@dessent.net>
Message-ID: <Pine.LNX.4.60.0407082058010.7086@zeno1.math.washington.edu>
References: <010701c464f4$398e2030$4e6510ac AT ds DOT tao DOT co DOT uk> <Pine DOT GSO DOT 4 DOT 58 DOT 0407081027371 DOT 11665 AT slinky DOT cs DOT nyu DOT edu> <013301c464fe$e2e425d0$4e6510ac AT ds DOT tao DOT co DOT uk> <Pine DOT GSO DOT 4 DOT 58 DOT 0407081124080 DOT 11665 AT slinky DOT cs DOT nyu DOT edu> <Pine DOT CYG DOT 4 DOT 58 DOT 0407081405270 DOT 1032 AT edocomputer> <Pine DOT GSO DOT 4 DOT 58 DOT 0407081549530 DOT 2377 AT slinky DOT cs DOT nyu DOT edu> <Pine DOT CYG DOT 4 DOT 58 DOT 0407081504350 DOT 1032 AT edocomputer> <40EDEF6B DOT A5A5F06 AT dessent DOT net> <Pine DOT CYG DOT 4 DOT 58 DOT 0407082005200 DOT 1064 AT edocomputer> <40EDF623 DOT AF728A26 AT dessent DOT net>
MIME-Version: 1.0
X-AntiVirus: checked by Vexira Milter 1.0.6; VAE 6.26.0.3; VDF 6.26.0.18
X-IsSubscribed: yes

*** Brian Dessent (ufobrian AT dessent DOT net DOT tv) wrote in the cygwin list today:

:) Nowhere did I claim that SHOULD was equivalent to MUST.  And yes I know 
:) the difference.
:) 
:) My point was simply that if a RFC describes a normative procedure then 
:) that lends weight to the argument that if at all possible, you should 
:) do it that way.  Read my last line again, "Just because you can do 
:) something [send emails with long lines] doesn't mean you should 
:) [because the standards ask that you not]".

Hello Brian,

  Yes, you said that. Let me explain why my answer was like it was. It was 
due to the fact that you brought a RFC that does not take any position 
about an issue to support a claim. In my opinion, this is the same as 
saying that Neruda said so. The fact that we do not send lines longer than 
80 characters is a historical fact, already well justified. That the RFC 
says so, is irrelevant, and if your final point is that "not everything 
that can be done should be done", although true is weakened by the text of 
the RFC, which actually allows it. In a general sense I agree with you, in 
this particular case, I don't because clients MUST be prepared to accept 
lines of length up to 998 characters. If they do not spend a few CPU 
cycles to transform this into a readable message is up to the programmer 
of such client.

  All of this means that you can not transform a mail message to a html 
just by adding tags, there must be some processing of the message before 
those tags are added, certainly adding <pre></pre> is a choice, not the 
best as it has been demonstrated.

  Having said all this, I think that the world is moving (slowly) toward 
flowed text (due to the fact that eventually most of "us" will read at 
least part of our e-mail in a PDA like electronic object, but that is 
still several years away), I think that long lines are going to be more 
popular with time. Do I like it? no, but I think it's unavoidable, and we 
should just be tolerant, because it has good benefits when you use the 
right tool to read such messages.

-- 
Eduardo
http://www.math.washington.edu/~chappa/pine/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019