On 2012-11-21, Jim Graham <spooky1...@gmail.com> wrote: > On Wed, Nov 21, 2012 at 05:02:50PM +0000, Tony's unattended mail wrote: > >> LF means "begin next line now". So as an author posting text to a >> forum, at what point do you need an LF? Not after XX width, >> because that makes poor assumptions about the readers medium (is it >> an LCD, or a phone?). > > So you don't make an assumption about the e-mail client of any > reader on the list...not even that their MUA displays very long > lines correctly, right? So, you can't assume that it wants very > short lines, or likes very long lines, or somewhere in-between.
I'm not making any assumptions based on a fixed length, short or long. Post 90s, accommodating *variable* width is more sensible than a width that is fixed. > I guess that means you can't send the message at all, right? > Somewhere, you have to make as assumptino. An author need not assume any particular fixed width. > At this time, the generally accepted assumption is to wrap at around > 72--76 characters Right.. one million smokers can't be wrong. > (with the obvious exception of posting code, etc., where lines may > often end up longer unless you escape the newline and continue the > line of code (indented, of course) on the next line. This is the problem with the fixed width approach -- the exception is not syntactically distinct from LFs that try to guess at the readers display. > As others have also mentioned, lines that don't wrap---not everyone > uses Mutt or other smart MUAs, and even if you do, in a wider xterm, > the longer lines can be much more difficult to read---they are for > me, anyways, so I usually just delete the message without even > bothering with it (if I'm using a wider xterm or an e-mail client > that doesn't correct the line length, or gets it wrong). This is where I make an assumption. When the need for an assumption arises as to whether others have poor quality tools or high quality tools, I do not assume the other party has poor quality tools if the approach that caters for poor quality tools will hinder users of high quality tools in some way. Punishing users who have high quality tools to favor lesser quality software serves as an enabler for lousy quality to proliferate. If we didn't think along the bandwagon lines of going with the crowd, developers would have some pressure to improve the tool.
