Just passin' through.... Xah Lee, on Aug 22, 2:43 pm wrote: Unix, RFC, and Line Truncation [snippage] > There is no reason for a paragraph encoding to be splattered with end > of line characters, nor the human labor expended. There is reason for > paragraphs to be displayed not too wide, and that is readability. What > the unixer could not get clear of is a distinction of concepts. Because > their fantastically hacked-up operating system operate by the principle > that lines should not be some 80 chars or else it will be truncated and > *silently* too, thus it became _necessarily_ their _habit_ and thought > that line truncation business is natural and a human duty. Unknown of > these setups, the unix geeks go by their presumption that all text > should be hard wrapped, as if parameters should be hard-coded.
I've seen this argument before. There's at least one VERY good reason to hard-code linebreaks in text: to preserve a covert channel. It's really easy to structure plain text in such a way to include super sekret messages that can only be properly decoded when the original formatting of the text is preserved. Assuming that all of us are agreed that plain text is the correct lowest-common denominator in email and Usenet communications, it makes sense to allow for additional personal expression by way of enabling users to encode additional information in the formatting of their messages. So, while Mr. Lee (who is not alone) is apparently of the opinion that paragraphs should be formatted according to the transient size of the newsreader window, his preference destroys a channel of expression available to the putative author -- if free-flow paragraph structure is mandated by the messaging standards and conventions of the text messaging community. Personally, I think the status quo is fine. People who wish to insert line breaks where they wish in their paragraphs may do so, and others may rely (or not) on their software to format their messages. In the long term there are more pressing problems. Sould we, for instance, extend the plain text 'conventions', which are largely concerned with 7-bit ASCII messaging, and all the associated software applications to work with unidcode character sets? Simplicity is good and all that, but this is a multi-cultural, multi-language world. Locking out the non-English speaking population from Usenet or (worse) from manually interoperating with basic Internet protocols (for instance) seems rather short sighted. I do not mean to start a flame war here; I am just trying to point out the obvious. People like Mr. Lee, as well as many, many application deveolopers are well-meaning but misguided. They would unnecessarily complexify things that should be simple and simplify things that should be complex. I, for one, am continuing to think about these issues because I see no simple solutions and have no magic bullet to offer that would solve these perennial difficulties of prereference, clarity, and common sense. Perhaps one day we will converge on near optimal solutions to these and like issues; which will be coded and formalised in standards, and which will stand for the indefinate future. Regards, Steve -- http://mail.python.org/mailman/listinfo/python-list
