This is an account of my thinking about when to start using Mozilla
1.0rc1 or its successors for browsing and email in place of Netscape
4.77/4.79 on Win2k/Win98SE. There is a mixture of material here, from
low-key observations and configuration details to what I consider to be
important bugs. Please see my focus on problems as an expression of my
enthusiasm for the Lizard growing stronger still!
I have written this for the Mozilla Mail/News and Editor newsgroups:
http://www.mozilla.org/community.html
with separate messages so follow-ups stay in each newsgroup, and the
Link mailing list: http://sunsite.anu.edu.au/link/
I mention some apparent bugs here, including one which is in Bugzilla
(multiple Bcc:s) and some which may not be, such as:
1 - Plain text messages having additional spaces added to indented lines
when they are sent or when they are saved to Drafts.
2 - Anomalies with invisible spaces in compose, and these being
transferred to the following line when the message is saved to
Drafts.
I have been using Mozilla for HTML editing for 6 months or so, despite
its lack of spell checker and its various awkwardnesses, because I like
its ability to deal with tables and am glad to be rid of some pesky bugs
in Netscape 4.7x. For now I will not discuss problems I perceive in
the HTML Composer for web pages. I have no interest in sending HTML
email: http://www.firstpr.com.au/sys-admin/HTML-email/
There are many reasons for wanting to use Mozilla, and I won't list them
all here. I am concentrating on problems I encounter and any
workarounds I can find. Please write to me directly or reply to this
message on the newsgroups to correct or improve on my understanding etc.
There are a number of things I need to be happy about before switching
to Mozilla for browsing and email - all to do with its email abilities
in my LAN-based IMAP setting. I have not tested the Mozilla browser - I
am assuming it is fine, although I imagine there are gotchas with it as
well, since so many sites are tested only with MSIE. I spend a lot of
time on email and for various reasons, I want to have a single program
for browsing and email, running on Windoze. Ideally it would be my HTML
editor too.
Mail filtering is on my Red Hat server on the LAN, with messages from
30+ mailing lists being sent to their proper mailbox, but also sent to
the Inbox, tagged for deletion:
http://www.firstpr.com.au/web-mail/Maildrop-mods-filtering/
This replicates the functionality of Netscape 4.x's mail filtering, but
entirely on the server so it doesn't matter what clients I use.
Overall, I am thinking of switching to Mozilla . . . . but the lack of
spell checker and the problem with spaces being added to indented lines
seem to preclude it at present. Also, I get lots of spam and viruses
every day, and I prefer to move them to mailboxes with a very quick
sequence of keystrokes - but Mozilla makes this a complex
trackball/mouse or cursor-key job, whereas with N4.7x is is very easy,
for instance "Alt M, M, 0, 2".
Spell checker
-------------
Mozilla 1.0rc1 has no spell checker. Here are some links about this:
http://bugzilla.mozilla.org/show_bug.cgi?id=56301
Original bug with lots of discussion about adding a spellchecker.
http://spellchecker.mozdev.org/
A suitably licensed spell checker, with source and some
Windows .xpi files which I don't know how to install. There
are bugs, like crashing 1.0rc1 and there's no screenshot, so
I don't know what it does.
http://www.mozilla.org.uk/docs/spell-checker-faq.html
A FAQ which is probably out of date, since it does not mention
the above project.
Here are some comments on the proprietary spellchecker used in N6.x:
1 - There are no keyboard shortcuts for the Ignore, Add Word, Change
etc.
2 - There seems to be no obvious way of editing the user dictionary.
I often need to do this when I mistakenly add a word to it.
In my Win98 system the file is:
c:\WINDOWS\Application Data\
Mozilla\Profiles\(user\gobbledegook)\custom.dic
3 - It would be truly excellent if, like Word, there was an Undo
feature affecting both the message and the user dictionary. I
spell-check rapidly and often make mistakes.
I composed most of this message with Mozilla, without the benefit of
spellchecker, but got sick of the problems when saving to Drafts, so I
completed it with N4.77 and used its spell checker.
General usability
-----------------
It would be nice if the default for opening a mailbox would be to go to
the end with the most recently received, or sent messages, rather than
opening at the top, where the oldest ones are. N4.x is the same. I
still want the earlier emails at the top and the latest ones at the
bottom.
N6.2.2 has different icons in the Windoze Alt-Tab task list for the
various types of window: browser, mail, news, HTML composer etc.
Mozilla doesn't have this, which makes it trickier to switch quickly to
the right window.
N4.7x automatically opens the mail-news client with the Inbox selected
and all its contents visible, but Mozilla/N6 opens with the name of the
"mail account" selected, making it necessary for me to click on "Inbox"
to see my incoming mail. (Actually, when I tried this with N6.2.2 I had
to muck around opening a collapsed "mail account" to see the Inbox
again, and selecting other mailboxes and then the Inbox again before it
would show me the Inbox messages. I don't feel like chasing such
seemingly-intermittent awkwardnesses, but they have occurred for me. )
Opening a new mailbox
---------------------
A long-standing (April 2000) bug has been that double clicking a mailbox
to open it in a new window also leaves the original window pointing at
the new mailbox.
http://bugzilla.mozilla.org/show_bug.cgi?id=35389
The workaround with M1.0rc1 is to use the right trackball/mouse button
to select the new mailbox and then press "W" or use the Open in New
Window option.
Curiously, when I tried this "open in new window" approach with N6.2.2
on Win98SE, the same problem occurred: the original window was pointed
to
the new mailbox as well - so that seems to be a N6.x bug. I have
repeated this several times, including immediately after starting the
program. In the latest repeat, the two resulting windows have the left
pane with very different sort order for the mailboxes "Trash" etc.
and for the mailboxes which contain other mailboxes.
Sort order of mailboxes
-----------------------
These are observations, not problems.
It seems that Mozilla sorts mailboxes in the left pane according to:
Inbox first (With Courier IMAP, all other mailboxes, including
those which contain other mailboxes, are contained
within the Inbox. This is how Courier IMAP works.)
Certain "special" mailboxes
These are ones configured (in this mail account or
another one, or probably a newsgroup account too)
as places where copies are saved (as in a "Sent"
mailbox) or which are nominated for storing "Drafts"
or "Templates".
The "Trash" mailbox is here too - its name is always
"Trash". I never use it. (BTW, here in Oz, "trash"
is regarded as a distinctly American work - we have
rubbish bins, not trash bins.)
The sort order seems to be Drafts and Templates
first, then one or more "copy" mailboxes in alpha
order.
General mailboxes in alpha order
These include mailboxes for messages which are
directly within the Inbox, and those which are
holders for other mailboxes.
The alpha order in Mozilla seems to ignore a leading
"-", so my naming of a mailbox "-Spam" to bring it
to the top in N4.7x has no effect in Mozilla - it is
sorted as if it started with "S".
Keyboard shortcuts selecting mailbox to move message to
-------------------------------------------------------
N4.7x has numeric and alphabetic shortcut keys when navigating the
tree structured directories for Move/Copy Message. This is very
helpful, since many times each day I want to move something to a mailbox
for spam, and this is "Alt M, M, 0, 2". (I want it to be a location at
the top of my mailbox tree, for easy access and so that adding new
mailboxes does not alter the numeric location of the spam mailbox. The
whole idea of dealing with spam is to make it very brief and stress
free.) With Mozilla or N6.x the only way of doing it is drag and drop
or to use cursor movements to navigate to the appropriate mailbox. For
me, this involves selecting the server, its Inbox, the mailbox folder
and then the mailbox with the trackball or cursor keys, which involves
unwanted and time-consuming hand-eye coordination.
A workaround might to be to delete the spam, but I prefer to keep it so
I can freely turf suspected spam in there, with just a moment's thought,
knowing I am not risking deleting a genuine message. If something wasn't
really spam, or if I need to refer to it later as part of spam
reporting, then I still have it.
Another workaround might be to create another "mail account", with its
own mail server settings, just for spam. I could make its name start
with "0" or "A" or whatever so it is the first, default, "mail account"
I would reach after "Alt M, M". Then a simple right cursor key and
Enter would put the spam in that account's Inbox.
Many times each day I want a quick way of disposing of spam and viruses
- with minimal keystrokes and no trackball/mouse stuff or having to
think or look at menus to decide which cursor key to use.
Ideally, a "Control K" to KILL a spam (really move it to a predefined
mailbox) would be the best thing!
There is some doco at:
http://www.mozilla.org/unix/customizing.html
about key bindings. I am not sure how up-to-date it is, or how it is
relevant to Windows Mozilla. But perhaps there is scope there for
configuring the Lizard to gobble a spam and virus emails with a simple
keystroke such as a function key.
On 24 April 2002 on the mail-news newsgroup, Vincent Keunen requested a
configurable arrangement where a single keystroke, such as Control M,
would serve as the Move command, with a configurable list of single
keystrokes, with each keystroke pointing to a user-specified mailbox.
This would be excellent. Then, the very common task of moving messages
would be a lot faster. Perhaps too a log of message movements would be
good, in the event that we accidentally move a message somewhere wrong
and can't find it again.
Fixed header box when reading mail - and other header matters
-------------------------------------------------------------
I did not like this initially, but in its current M1.0rc1 form, I think
it is OK. Firstly, on screen it can be minimised (with the little box
at the left) to be a single line. Secondly, when printing, irrespective
of the current mode of that on-screen box, the headers are printed in
ordinary text, without the grey box background which used to be the
case.
However, the printing of headers is not as nice as N4.7, which
right-justifies the end of of the header name so it can left-justify all
the contents of the headers.
Multiple "Sent" mail mailboxes
------------------------------
This is good news - and a suggestion for a more elegant approach.
As far as I know, most or perhaps all email clients are deficient in
that they do not allow multiple mailboxes to be useful for storing Sent
messages. Any mailbox can store such messages, but what is needed is
for the client to list the *To:* address, rather than the "From:"
address.
I want a Sent mailbox for the last year or so, and then one or more Sent
mail folders for previous years, and another for very large messages. I
could very easily want quite a few sent mailboxes, for personal,
business, different years etc. (Actually, the really big puzzle is how
to make it easy for a mortal user to keep tabs of a correspondence from
one place, even if the received and sent items are in various
mailboxes.)
With N4.7, my workaround was to use the Newsgroup Sent setting to make
the program display the "To:" address for a second mailbox, which was
really where I kept my previous year's sent mail. (I don't write many
messages to newsgroups.) This workaround helps, but it can only add one
extra "Sent" mailbox. But with Mozilla / N6.x, there is are multiple
possible mail accounts, and each has a setting for "Sent:" for email.
So by generating one or more dummy "mail accounts", using an email
address which Mozilla/Netscape is happy with, each new "mail account"
enables me to nominate another mailbox which will display the "To"
address rather than the "From". (Likewise, I think dummy "newsgroup
accounts" could be used for this purpose as well.)
This is good, but it is a fudge which is not at all obvious to most
people. A better approach would be to extend the existing arrangement
by which we can choose which columns are displayed in each mailbox.
That is from the little box at the right at the top of the headings.
From there, the columns can be turned on and off, and then the
column
widths can be changed and the columns re-ordered by dragging them
around. At present, this will give the option to show only "Sender",
rather than "To" as well, unless the mailbox has been nominated as one
used for saving copies to, in one of the "mail accounts" - in which case
only the option for displaying "From" is available.
(Note the above paragraph has extraneous spaces in front of "From" and
that line has been pushed to wrap to the next one. This is an
uncorrected example of the space-adding bug I discuss below. I never
put a leading space on any line there as far as I know - it is in the
middle of a paragraph, so maybe I accidentally and invisibly put two
spaces after the previous work and then the leading space appeared by
some bugulacious means and then grew into multiple unwanted spaces every
time I saved to Draft and re-edited.)
Synching IMAP folders
--------------------
If new messages arrive in an IMAP folder (other then the Inbox) by means
other than the current client (this instance of Mozilla/Netscape) then
how does one easily find this out, or see the new messages in a mailbox
which is already open. This could result from server-based mail
filtering, or from another client putting the messages into or taking
them out of a shared mailbox.
It seems that with M1.0rc1 and N6.2.2, the situation is unchanged from
N4.7x - there is no explicit command to tell the client to refresh its
understanding of what is in the IMAP mailbox. The workaround seems to
be to select another mailbox and go back to the first one. Where the
mailbox is within another mailbox, and the enclosing mailbox has no
messages, then it is good to click on that enclosing mailbox, since this
will take no time to read the zero messages from it. So this involves a
few trackball/mouse clicks and a few seconds to make the client look
freshly at the mailbox.
I think there needs to be a command to refresh the mailbox which the
current window is looking at.
There was discussion on 28 April 2002 (and probably many times before)
on the Mozilla mail-news newsgroup about the desirability of a single
command to resynch all IMAP mailboxes. But if you have as many
mailboxes as I have (220 or so) this would be onerous and slow even on
the LAN and would take half an hour or more if I was connected by a 9.6
kbps cellphone session.
Nonetheless, according to the *most* informative page:
http://www.hmetzger.de/net6e.html#39
there is a config option in user.js to do just this.
Smartypants display of "> " and *bold*
--------------------------------------
I hate this stuff! Is it too much to ask just to see the straight text?
I don't want those vertical bars, or boldfacing of things the email
client deems to be inside asterixes etc. At least the terribly
consumery default of turning :) colon-brackets into coloured smilies can
be disabled in "Edit > Preferences > Mail & Newsgroups > Message
Display".
Thankfully, there is a way of getting rid of these things. Create a
file in the profiles directory called user.js, containing the lines
below. To find the profiles directory, see:
http://gemal.dk/mozilla/profile.html
- - - -
// 1: Get rid of vertical line display of "> " quoting.
//
// See: http://www.hmetzger.de/net6e.html#12
//
// Probably the only one needed is the first one - but the above
// page recommends the last one too to stop it doing format_flowed
// display.
user_pref("mail.quoted_graphical", false);
user_pref("mail.quoteasblock", false);
user_pref("mailnews.display.disable_format_flowed_support", true);
// 2: Get rid of interpretation of *bold* etc.
//
// See: http://www.hmetzger.de/net6e.html#13
user_pref("mail.display_struct", false);
- - - -
I understand that some or many Mozilla developers share my vision of
directness and simplicity, but clearly not everyone agrees, or thinks
that this is what "ordinary users" really want.
Security and HTML emails
------------------------
I would like to be able to prevent all emails from displaying as HTML,
and to display the plain-text equivalent they should include, unless I
gave a specific instruction to display the HTML.
Furthermore, I want to be able to prevent the email client from
accessing any external server as a result of the message. The current
arrangement is the moment you view (or receive and so view) an HTML
message, your computer will dutifully go off and load images from remote
servers. This is a complete privacy and security nightmare - unless
you don't mind anyone and everyone tracking your location and actions.
I am not sure, because my installation used an existing Netscape
profile, but I hope that the default is to not execute Javascript in
email or news messages.
Additional leading spaces when sending and saving to Draft
----------------------------------------------------------
Unless I hear it has already been reported, I will create a new bug for
this.
When using the plain text editor, if there is a line with one or more
spaces at the start, sending the message or saving it to Drafts adds an
extra space. This is a very easy bug to reproduce:
Compose a message, addressed to yourself. In the message body, type
a space and then "Boo!". Send the message and read it. There will
be two spaces before "Boo!".
The problem also exists in saving to Draft - the resulting file there is
corrupted with the additional space. The file being edited is fine.
I use leading spaces a lot: to indent URLs and to write point-form
paragraphs. This bug is a very strong reason not to use Mozilla for
email, since it pervasively and invisibly corrupts my messages - and
progressively corrupts them more each time I save to Draft and re-edit
it.
If I had sent this with Mozilla, all my lines with leading spaces would
have been indented one space further.
Other compose whitespace / stuck cursor bugs
--------------------------------------------
Likewise, unless someone tells me these have been reported, I will make
new bugs.
With the plain text editor, clear all text and type:
Blah blah blah blah blah blah blah blah blah blah blah blah blah blah
with the wrap length set to the default of 72. (Edit > Preferences >
Mail & Newsgroups > Composition > Wrap plain text messages at . . . )
After pressing the last "h", the cursor is on column 70. Pressing a
space and then a "b" is fine - the text wraps to the next line.
Likewise, it copes with 2 spaces and a "b" and 3 spaces and a "b".
But if, for some reason, you press 4 spaces, then the cursor gets stuck
back at column 70 and stays there no matter how many more spaces you
press. If you get frustrated and press twenty spaces, then you might
have to press left arrow or backspace nearly that many times to get the
cursor to move again.
If the final word is extended to "blahxyz" then pressing a single space
after that has no visible effect on the cursor. From "blahxyz",
pressing a space and a "b" does wrap OK. But if you get frustrated at
the lack of cursor movement due to one space, and press two or more
spaces, then still no movement occurs. Lets say you press the space bar
6 times. Then, by pressing "b" this will wrap to the next line. But
there are spaces in the file, which cannot be seen. If you add "ABC" to
the start of the first line, then it wraps all your spaces to the start
of the next line!
Now repeat the exercise, starting with the "Blah blah . . . blahxyz"
line. Press the space bar 6 times and then type "b". All looks well,
but the hidden spaces can come back in another form: Save the message
to Drafts and then open it again (it is the saving which is the
problem). Now we have:
Blah blah blah blah blah blah blah blah blah blah blah blah blah blahxyz
b
The same thing happens if you send the message. The result is very
different from what you see on screen beforehand.
So it can be seen that invisible accidentally entered spaces can corrupt
the message visibly with leading spaces on the next line when sending,
or when saving to draft. When the draft is re-edited, this is a leading
space situation which:
1 - Will lead to extra leading spaces on the second line when the
message is sent or saved again to draft.
2 - May cause the second line to wrap.
Also, copying and pasting from the compose window into any application
leads to the same problem: hidden spaces beyond the wrap limit on one
line appearing on the next line.
These are not esoteric problems - they tripped me up when I was
composing this message with Mozilla.
N4.7x's plain text editor is a pain because its on-screen wrapping
depends on the width of the window, and is not directly related to the
wrapping which is done when sending the message or saving to draft. A
little blue triangle is kindly provided which enables the window width
to be set about right. But N4.7x's handling of whitespaces and
wrapping is better than Mozilla's - there is never a situation where
more than one space remains invisible.
Extra Bcc: with every save to Draft and re-edit
-----------------------------------------------
Every time I open a message for editing, say from the Drafts mailbox,
where I saved it from a previous edit, there is an additional line of
Bcc: added (since I configured a Bcc: address in the "Copies & Folders"
part of the "mail account" settings). This happens despite the fact
that there is already one or more such Bcc: addresses there. This
appears to be covered by current bugs including these, which I guess are
duplicates:
http://bugzilla.mozilla.org/show_bug.cgi?id=63639
http://bugzilla.mozilla.org/show_bug.cgi?id=140913
Cursor movement in address lines
--------------------------------
When editing the lines in the To / CC / Bcc part of the message compose
window, the up and down cursor keys both move the cursor to the right of
the current line, rather than up or down.
Some config items
-----------------
The default is to compose emails in HTML. To change this, deselect
"Compose messages in HTML format" in "Edit > Mail & Newsgroup Account
Settings".
I want to see messages which are flagged for deletion. This requires a
change to the "Server Settings" part of each mail account settings, by
changing "When I delete a message" from "Move it to the Trash folder" to
"Mark it as deleted". Then Mozilla/Netscape works fine with my
server-based mail filtering system - and also deletions can be reversed.
This means for N6.2.2 I use "Alt F, T" to compact (expunge) the
mailboxes, or (annoyingly different from N4.7 and N6.2.2) for Mozilla,
it is "Alt F, F".
(Note Mozilla's corruption in the above paragraph - leading spaces
introduced and propagated during successive save to draft and re-edit
cycles.)
Print and print preview
-----------------------
Mozilla and N6.2.2 lack N4.7's "Print Preview" function. Maybe this
will be implemented later.
A welcome new feature is the ability to print a message being composed.
With Moz1.0rc1's plain text composer, this just prints the text, without
subject, sender, recipient etc. But I think this is a really valuable
feature - to be able to print out a message and read it on paper, which
is a different setting from the screen, and so more likely to help me
see typos, expression errors etc. With N4.7x, it was necessary to save
to Drafts, then open Drafts, open the message and print it.
Address book
------------
N6.2.2 has no search facility for the address book, but M1.0rc1 has an
all-singing-all-dancing AND or OR multiple field search facility.
Sort by date / order received
-----------------------------
With IMAP at least (I haven't used POP for years) the client has two
possible dates for each message which it could use for displaying or
sorting a mailbox (lets leave time-zone correction out of this . . . ):
1 - The SMTP Date: header, as created by the sending client (which could
be set to the wrong date, time or timezone, so could be erroneous).
2 - The "received date/time" in the mailbox. This is not part of the
message as such. In an Mbox format mailbox, it is the date time
of the "From . . . " line which starts each message in the mailbox
file. In a Maildir mailbox, it is the file date of the message
file. (See my site for an Mbox to Maildir conversion script.)
N4.7 always displays (in the Date column of the right pane) and sorts on
the SMTP date.
Mozilla / N6.x does the same by default, but in the View > Sort order
menu, you can make it sort on received date. This reverts back to SMTP
date any time the "Date" column header is clicked (as one would to sort
by date, or to reverse the sort order). This is potentially a very
useful feature! I understand that some other clients, such as MS
Outlook Express typically or always sort and/or display by received
date.
The selection of "Order received" is persistent after closing and
re-running the program, but when it is first run in this state, there
are no arrows on the Date column header or any other header indicating
how the messages are sorted.
I think there is potential for user confusion here. There is no clear
visible difference in the column headers between sorting on Date and
Receive Order - and there should be. The View > Sort order menu item is
too cryptic and unlikely to be discovered.
What might be cleaner, in some ways at least, is to have separate
columns for Date and Received date, enabling them both to be displayed
and sorted on as desired. The receive date is often an important item
of information about an email, but unless you scrutinise the headers
(and potentially convert from the server's timezone to a local timezone)
then there's no easy way for people to see when a message was received.
Searching messages
------------------
I often want to search only some messages in a mailbox - for instance
the most recent week or so. Maybe IMAP search commands can't handle
this, but it would be nice to be able to search only those messages
currently selected in the right pane.
Speed of logging mailboxes
--------------------------
I have sometimes found Mozilla to be really slow looking at the contents
of a largish mailbox, say 4000 small to moderate length emails (on a
fast Courier IMAP server with Maildir mailboxes, which have a separate
file for each message). Yet one much longer mailbox works fine, and
N4.7x is fast for all these mailboxes.
One 12,000 message mailbox took over 5 minutes to log with Mozilla on a
mobile Celeron 466 MHz. Then Netscape 4.77 on the same machine,
took 2 minutes after I cleared its IMAP cache file. Since there could
be server file caching effects on this, I then cleared Mozilla's IMAP
cache file for that mailbox. Mozilla logged the mailbox in 45 seconds!
So I am not sure what to say, except that I think in the past that I
have had reproducible slowness on some mailboxes which was not
explicable by server delays.
HTML instead of plain text and vice-versa
-----------------------------------------
In the Help text for Rewrap, I found that it is possible to select the
opposite of the default plain vs. HTML editor by holding down Shift
whilst clicking Compose or Reply.
Text wrapping, and the Rewrap command
-------------------------------------
In the composer's Options menu, there is a Rewrap command. After some
experimentation and reading the Help text, I still wasn't sure what it
did. (But see below on wrapping and quoted text.) The Help text:
This command is primarily useful when you are replying to a message
where the original message is quoted in your reply, and the original
message contains long lines.
indicates to me that one or more long lines with a single "> " quote at
the start could be reformed automatically to be multiple shorter lines,
each with a "> ". But I couldn't get any sense of if it like this.
There is a bug about extraneous lines being added by Rewrap:
http://bugzilla.mozilla.org/show_bug.cgi?id=121898
I found that messages are saved in Drafts wrapped to the current limit,
with ordinary 0A newlines. The paragraph end has just a newline, but
those line ends caused by the wrap limit are saved with a space and then
the newline. This cause paragraphs which are typed in (or pasted from
another application), with trailing spaces between the last printable
character and the newline to be saved without those trailing spaces.
See the discussion below on "format=flowed". (This is probably OK, but
if you were composing a sparse table of text and wanted to cursor around
the table freely, then any blank lines you fill with spaces for this
purpose would have all their spaces deleted, stopping the free cursor
movement. So even here, the desire to program for format=flowed
viewability, which may never be required of the current message, results
in the program deleting things the user has typed or pasted in.)
But if the message currently being composed - resulting from typing or
pasting, but not from reading a saved Draft - is copied and pasted to
another application, each paragraph is a single long line. Trailing
spaces on paragraph ends are visible in blue when selected, and are
conveyed by copy and paste.
Using Rewrap on selected text, or the whole message (with no selected
text) causes the internal representation of the text to be wrapped - as
reflected in copy and paste, and in the subsequent lack of automatic
wrapping on screen if that text is altered. (Rewrap also seems to get
rid of trailing spaces on paragraphs and automatically wrapped lines.)
So Mozilla is like N4.7x in that text remains fluid and automatically
wrapped on screen (but with N4.7 you must have the right window width!)
but is saved in a hard-wrapped form when saved to a Draft. This is a
natural but regrettable result of there not being a "soft-newline"
character which it would be kosher to write to a mailbox, where it might
be read or sent by programs expecting conformance with Internet mail
standards. (However, as noted below, the "space, newline" does mean a
"soft newline" if the file is interpreted as "format=flowed".)
So what practical use is the Rewrap command? (See below on wrapping
quoted lines.) It doesn't seem to alter the on-screen appearance of
things, or the way they will result in a saved file or the final message
when sent. It only seems to affect the internal storage of Composer,
and what can be copied and pasted from it, by fixing newlines into the
text according to the way it currently looks. (It deletes trailing
spaces as well.)
It doesn't try to replicate "> " quotes as it wraps a long line to
multiple shorter lines. (Pegasus did a good job of this, until it was
"upgraded" to do rich/HTML mails.)
Each composer window does not notice any changes to the Preferences for
wrapping. Changing it from 72 to 60 does not affect the display, Rewrap
behavior, copy and paste or save to Draft behavior of an existing
composer window, but it does affect subsequently opened compose windows.
So the Rewrap command can't even be used to wrap parts of the message to
different widths.
What about wrapping and words (typically URLs) which exceed the wrap
limits? Mozilla will never chop or truncate such URLs, except, when
sending or saving to draft, if it would make the line exceed the 998
character limit imposed by RFC2822.
But how does it handle long URLs - those which exceed the wrap limit? I
found with N4.7x that when I tried to put a long URL in a message with
four leading spaces to indent it, as I do most URLs, that the on-screen
representation would be to add a blank line and start URL at the left
margin. I thought, in the past, that the resulting message would
reflect my intention, not what I saw on screen when writing it, but I
find that with N4.77 the message does have the new blank line and the
URL starting at the left margin, just as it appears when writing it.
So it is with Mozilla. Although a copy and paste from the composer
shows the internal data is what I want, both the on-screen display and
the resulting message won't do what I want. Its a minor matter which
crops up fairly often.
Wrapping and quoted lines
-------------------------
After reading a mail-news message by Jens Vogel on 28 April, I found out
more about the wrapping process.
Lets say there is a message with lines as long as 72 characters, but for
experimental purposes, I have set the wrap limit to 60. When I reply
to it, the lines all have a "> " added to them, so some are 74
characters long. These lines are *not* limited on screen or in the
final message to the 60 character wrap limit.
The wrap limit will be applied if:
1 - The Rewrap command is used - for some selected text, or the whole
message if no text is selected.
or
2 - If the message is saved as a draft and re-edited.
In this case, the message is saved without any alteration of the
long lines - each, in the test I did, had a newline immediately
following the last printable character.
The wrapping occurs when the message is opened for editing again.
The result, predictably, is a mess.
Format=flowed
-------------
By default, Mozilla sends plain text messages with:
Content-Type: text/plain; charset=us-ascii; format=flowed
According to my incomplete understanding of RFC2646 this means that the
receiving device is told to reflow text if it needs to, for instance to
fit a narrower or wider screen. From what I can see, there are
elaborate but sensible suggestions for how to do this with plain text
messages which were written with longer lines. The message is sent with
a space before newlines which were created by the automatic wrap process
- with a paragraph end being indicated by a newline not preceded by a
space.
http://www.hmetzger.de/net6e.html#10
As far as I know, this "format=flowed" Content-Type should not cause any
problems - but if anyone is likely to be offended by a client displaying
text differently then the way I wrote and saw it, its me!
There is a way of turning it off as mentioned at the above URL and at:
http://www.mozilla.org/unix/customizing.html
As far as I can see, the composer does not use the "format=flowed"
nature of the saved Draft when re-editing the message, to automatically
wrap paragraphs to whatever the current wrap limit is - but I can
imagine this would be a good thing to do, since it would preserve the
wrapability of paragraphs, which are currently frozen into lines when
the message is saved to Draft. Akkana discussed this on the editor and
mail/news newsgroups on 6 March 2001.
Conclusion
----------
I would not use Mozilla for email until these bugs of extraneous spaces
(sending and saving drafts) are fixed, and until I could get some kind
of spell checker going. Hopefully, it won't be long.
- Robin
http://www.firstpr.com.au http://fondlyandfirmly.com
