Message-ID: <>
Date: Tue, 16 Jun 1998 18:02:57 -0700
From: Jamie Zawinski <>
Newsgroups: netscape.public.mozilla.mail-news
Subject: Re: Wordwrap in the Mail/News Editor Sucks!!!

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:

  1. The plain-text message composition window:

    1. Text must visibly soft-wrap at a configurable column (say, 72) regardless of the width of the window.

    2. Lines that begin with ``>'' at the beginning of a line must make that line be exempt from this wrapping: they must not wrap at all, and a horizontal scrollbar must appear on the window if necessary.

      (``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.)

    3. The ``>'' lines should be in another color/face, to make it apparent that they're behaving specially.

    4. The font used for editing must be fixed width, even on the Mac.

    5. Bonus points if typed URLs are highlighted (selectable?) in the same way that they are when messages are displayed.

    6. Bonus points if the wrapping column is some kind of visible ``slider'' at the top of the window, with a number next to it, with a big red ``stop'' mark at 79. This would eliminate the need for the ``wrap long lines'' preference on the composer.

  2. The HTML message composition window:

    1. It must deal with whatever complicated issues there are related to citations, and to their editing.

    2. It must generate HTML that is as readable ``in the raw'' as possible, and hopefully, as conformant to the HTML spec as possible, since we really get beaten up about that in the mail/news world way more than in the web-page world.

    3. It must deal with multipart/related sensibly, and in a way that makes it clear what images are being sent with the message, and what images are merely external references.

    4. Bonus points if typing or pasting a URL into the text area wraps an equivalent HREF around it.

  3. There must be a way to switch between the two modes, without having to delete the window first!

    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?

[ up ]