Message-ID: | <358715C1.728E5C20 | |
---|---|---|
Date: | Tue, 16 Jun 1998 18:02:57 -0700 | |
From: | ||
Newsgroups: | ||
Subject: | Re: Wordwrap in the Mail/News Editor Sucks!!! |
> No really, he's right. The composer window should show exactly what > will be sent, including wrapping to 72 columns, including signature, > everything. > > Anything else just skewers hapless users who don't even realize > they're committing netiquette violations or don't realize the columns > aren't going to line up when the last minute changes are done behind > their back before sending.
I agree with this in principle, but it's a two-edged sword. In Mozilla 2.0, the composition window did word wrap, and when the message was sent, it inserted hard newlines into the message exactly where on-screen wrapping occurred. Sounds perfect, right? Well, what happened was, most people ended up sending hundred-column messages, because a common habit was apparently to maximize (or otherwise widen) the window while editing (probably in order to make the cited text be readable.)
In 3.0, I changed it so that it always wrapped at 72 columns regardless of window width, and that worked better. And it was really the only thing that could have been done at the time, since rewriting the entire composition window (i.e., reimplementing the text field on all three platforms) was just not an option due to time constraints. It was the best solution available (since turning off word-wrapping altogether was not an acceptable option to any non-Unix users.)
For the rationale behind what 3.0 did (which is mostly-but-not-quite what 4.0 does) see the 3.0 release notes.
I know what the right way to fix this for all interested parties is; the UI isn't really all that complicated, but it has yet to be implemented.
And it's about time, dammit.
Here is how it should be:
(``Beginning of line'' means ``after hard-line-break'', not ``in the first column'', because a wrap-induced soft-break that leaves ``>'' in the first column shouldn't trigger this behavior.)
Obviously this can be a lossy transformation, and maybe the user should be made to confirm, but it should be possible to make the switch without creating a new window and cutting-and-pasting.
We first discussed doing this stuff before 2.0 shipped, and I consider it a disaster of moderately epic proportions that we made it all the way to 4.0 (and without a doubt, 5.0) without the text/plain editor having improved in any appreciable way. We can't let this continue! We really need to fix it this time around. This time for sure.
So who's volunteering?