Robin Whittle wrote:
> This relates to Mail/News and to the Editor - so I have posted
> this to both Newsgroups. I am posting from Netscape since I can't
> get Mozilla to access any newsgroups at news.mozilla.org.
>
> Mozilla (2001030308) under Windows 2000 (with SP1), Celeron 500,
> 256 M RAM. Using IMAP to a UW IMAP server on a Linux machine on
> the LAN.
heh
> I spent a week solid in November trying to characterise, find and
> fix bugs to do with whitespace in Composer. Three months later,
> the bugs are still there and I cannot spend this sort of time again.
Thanks for reporting those bug. But please understand that it also takes
time to fxi them.
> I am not optimistic about Mozilla at present. I hear the browser
> is great, but I need a solid email program to work with IMAP
> over my LAN.
I use both browser and Mailnews. The one that crashes is always the
browser (OK, maybe one of 100 crashes is Mailnews). Look at the
bookmarks stuff - endlessly buggy. Actually, I think, the Mailnews
client is pretty good, in comparison to the browser. (I wrote only minor
parts of the former, so the glory goes to the guys and gals at Netscape.)
> Here are my experiences in the first hours of trying to use Mozilla.
>
> No doubt some are recognised bugs.
>
> Even if you don't chase every thign I report - consider how
> frustrating it is to have this many problems in the first few
> hours of operation. I am not trying to do anything fancy.
I know :-(((. This frustrates me as well.
> I assume the extreme slowness
much improvement to come soon.
> There is no way of Shift clicking to select multiple emails.
worksforme.
> The Message > Move or Message > Copy no longer (compared to
> Netscape) has the ability to use keys (0-9, a-z) to quickly
> select the destination folder and mailbox. This compounds the
> previous problem by making email moving a stressful RSI
> generating operation with the pointing device.
drag and drop?
> (I have had some problems sorting mail too - but have not
> characterised them enough to report - it basically works, but
> not always, as it generally did with N4.76.)
there were some changes in semantics between 4.x and Mozilla.
> Printing produces shading around the headers. This is a waste
> of ink and makes it harder to read. (Note: it is a major step
> forward to be able to print from the email writing window!)
/me wonders: Why print email??? Save the planet! :-)
> The Sent mail folder *sometimes* displays the lines not as they
> were sent (wrapped, say, to 72 characters) but spread out to
> whatever the window width is. This is misleading and unhelpful!
No, it's a feature, see <http://www.landfield.com/rfcs/rfc2646.html>.
> One message even displayed proper line lengths (as was on
> screen when writing it, as was in the file in the sent folder)
> for one part of a paragraph and then switched to very long lines
> (the window width) for the rest - despite those lines being
> identically limited to <=72 in the file. Likewise, this
> appeared in the Inbox - but the source shows all the lines
> have similar lengths. What is going on?
see above.
> Maybe this is related to a field in the Content-Type header:
> "format=flowed".
yes.
> Mozilla sends with this set. Whatever
> it is, I don't want it!
too bad. actually, you can turn it off. see the newsgroup archive,
discussed not too long ago.
> Text is text.
Yes. But not all text is of the same type. (HTML contains text, too.)
Not even all "text/plain" is of the same type, as you just illustrated.
> The whole idea of
> an email editor and reader is to compose text and view and
> print it without any automatic smarty-pants "features"
> mangling it.
Says who?
You don't want urls to be clickable?
> Furthermore, *sometimes* it does not show comments as "> " or ">
> > " but as one or two vertical lines spanning the lines
> commented in this way. These lines are on screen and printed.
>
> This is pointless and obscures what has been written.
no, the opposite is true IMO.
> There is
> nothing at all wrong with a direct representation of text.
There is: ">" is a *convention* for quoting, which is not directly
understandable for new users. Even for advanced users, vertical lines
are easier to recognize, if nothing else, because there are graphics,
not text, and thus stand out.
> Likewise, the default to mangle plain text to show smilies and
> maybe other graphic versions of emoticons is a disruption
> and misrepresentation of what people write.
>
> What is needed is clarity and directness.
Then turn that stuff off. Not everybody likes the on-the-wire plaintext
format.
Actually, we have UI for it, but it is not (yet) checked in.
> Why spend
> effort on such features while the email editor is full of bugs
Sorry, but it's not your business to tell me what to spend my time on.
> For the same reason, email should default to plain text only.
It does. And fighting for that costed *a lot* of time.
> Let people send HTML if they consciously choose it, but there
> are so many reasons why HTML creates more complications than
> any occasional benefits it brings, that it should be kept as
> an opt-in feature, not a standard mode of operation.
Thanks for your insight.
> (BTW, as I think is already in a bug, we should be able to
> read plain/HTML emails as plain text - or force purely HTML
> emails into text.
30888, IIRC.
> Viewing HTML emails can lead to loading
> images from other sites, which gives away information about
> where and when the email was read.)
another bug, 27something.
> "Edit message as new" from the Sent folder automatically adds
> a Bcc line even if there is already a Bcc line in the message.
yes, I see that, too. file it.
> How do you set the height of the horizontal separator bar?
> Each time I double click on a mailbox, it opens with some
> default setting, not the way I adjust them.
dunno.
> News/mail editor (plain text mode):
>
> No spell check.
Not implemented.
> want to check the spelling after I have
> written most of the piece. Then go back and write some more -
> and then do a final check before sending. Currently there is
> a "spellcheck before send" option
Ever tried? Doesn't work. See above.
> Extra spaces seem to be added when the text is reformed.
Yes, and some spaces are deleted (at least in 0.6). This is bad.
> Sometimes:
>
> The newlines which are entered automatically when typing do not
> automatically reflow as the user adds and deletes words. They
> should. They should be "soft" carriage returns. They should
> be treated very differently from manually entered carriage
> returns. Ideally, they should stay this way when the email
> is saved, but because of the desire to save in a way which is
> "plain text" for other things to read, it seems that such saves
> as with Netscape Navigator, are destructive and turn the soft
> CRs to normal CRs.
I don't understand. As I read it, it is inconsistent with your above
rant about "Text is text". If you store "Text" as normal plaintext,
there is no way to store "soft" linebreaks. That's exactly what flowed
tries to solve.
> The need for soft CRs is one aspect of a proper, simple, plain text
> editor which cannot be generalised from an HTML editor.
What is "proper" (IYO)?
> But knowing
> a little about the internal plumbing of the Lizard's gizzards,
> I wouldn't like to try interfacing a plain text editor with the
> rest of the beast!
[...]
> Wordstar and Pegasus Mail did this - they gave the
> user direct, simple, control of what they needed to do.
>
> So why, with our Gigahertz CPUs and megabytes of RAM do we not
> have a plain text editor which actually does the ordinary things
> people need?
I think, your notion of "people" is a little to narrow. IMO, the HTML
editor, sending as flowed plaintext, is quite a good solution.
> Worstar on an 8080 was better - and that was 21
> years ago, running fine in 64 k of RAM.
Then use that.
[big snip - need to go to bed now. why did I write this mail, anyway?]
