Dear Ben,
Here is a partial response to what you wrote.
My reports on these newsgroups (I hope it right to post to both) is
intended to give insight into how at least one user who would like to be
enthusiastic about Mozilla finds it impossible to use for everyday
work.
In November, I did at least a week of *intense* work trying to
characterize whitespace bugs in Composer. I wrote bugs, compiled the
source on Linux and Windows (a drama I documented for others on builds
newsgroup because the Mozilla doco was out of date) chased through the
code and corresponded with a number of programmers. Two or so years ago
I put a similar effort into characterising a white-space gobbling bug in
Netscape composer - with detailed descriptions, example files etc.
To my knowledge, none of my investment and the time taken by people who
read and responded has resulted in any improvement to the programs. I
am not even sure that it has helped with the forthcoming solutions.
(Though later versions of N4.x no longer crash when deleting the null
characters which appear as a result of faulty HTML file line wrapping
and re-interpretation on reload.) I hope I am wrong in this assessment
- but I can't afford to spend another week for uncertain or minimal
practical benefit to anyone.
> > I assume the extreme slowness
>
> much improvement to come soon.
Fabulous! I have visions of the Lizard being fast, sure footed and
rigorously correct in its movements!
> > There is no way of Shift clicking to select multiple emails.
>
> worksforme.
I have tried repeatedly and with all possible Alt/Control/Shift
combination and nothing works for me. I installed 2001030308 on a
Windows 98 2ndEd machine and it behaved the same way.
> > 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.
> drag and drop?
Sometimes drag and drop is fine. Other times, I want to hit a few keys
without the stress of exact movement of pointing devices and hand-eye
co-ordination to navigate various levels of menus.
It may be perverse, but I keep the 4 or so SPAMs I get each day - rather
than delete them, in case I accidentally delete something important.
Also I report some of the SPAM, so I need a really quick way of
disposing it whilst not actually deleting it. I can do "Alt M M 6 1" in
a flash and with no stress.
> > (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.
I recognise mail sorting has changed. 4.x does not seem to recognise
"Sender" for me, and there are various header types it has to be taught,
but forgets with a fresh install. I haven't characterised the problems
I had with Mozilla. Mostly, it worked fine from the automatically
imported rules it got from N4.76.
> /me wonders: Why print email??? Save the planet! :-)
I have long correspondences with many people. I print the emails and
annotate them with a pen. Then I print my responses and keep them
together with bulldog clips and the like. I have boxes of it! It is
the only approach I can think of for tracking and annotating an in-depth
correspondence. I don't print trivial emails.
If there was a system for annotating emails (here, HTML would be handy!)
and for maintaining them in a system which meets several objectives at
once, then this would be an utter marvel and in some ways better than
the print and annotate system, because it would facilitate text
searches:
In addition to the simple mailboxes of received mail and sent mail there
needs to be a way of bringing all elements of a correspondence together
in date order.
There needs to be mailboxes (or at least something which resembles a
mailbox, if only it is a set of pointers to the emails, rather than
copies of the emails themselves) for the received mail and ideally the
sent mail for a particular correspondence.
These emails need to be sorted by the date and time they were physically
received and sent at this end - a challenge when some are dated
according to various North American and European time zones and I am in
Australia. (That is why I am super fussy about the date and time on the
printouts.) Several emails can be sent and received in a day, and the
ordering must be correct.
Ideally, there needs to be a way of searching the correspondence - both
received and sent emails in one search. (BTW it would be great to have
the search results be: viewing each email, or the entire correspondence
as one long file, with the searched for text highlighted, and with quick
stepping from one such item of text to then next.)
Currently, this grouping of the to and from correspondence into a single
place could probably be achieving with careful sort > copy rules for
incoming and sent mail. At present it is easier to print, annotate and
use paper-clips and bulldog clips.
By the way, it would be grand if mail searching could work for a
selected range of emails (say following a Sender sort of the Inbox and a
selection of one or more groups of senders). Maybe IMAP searching isn't
that flexible. Searching entire mailboxes is often not what I want to
do - especially with the Inbox, or a mailing list mailbox with a few
thousand messages. Currently, to search a subset of the messages, I have
to create an empty mailbox, select and copy the messages and then search
them there. By then, they are removed from the date-order context of
the original mailbox, which may make it harder to refer to emails from
other senders which precede or follow the ones I find with the search.
Such a complete management system for email would be fantastic. I
understand that emails fly even thicker and faster for people working in
corporations - so their email management workload with the current
techniques is heavier and collectively very costly.
> > 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.
>
> No, it's a feature, see <http://www.landfield.com/rfcs/rfc2646.html>.
Thanks for the reference to the new "text/plain" attribute:
"format=flowed" and for telling me it is configurable. A search finds:
http://www.mozilla.org/unix/customizing.html
which tells how to turn this off for sent mail and to disable the
interpretation of it for received emails.
Changing "> " and various emoticons to a graphic image is altering the
representation of what people write in a way which is beyond their
control. I don't think these should be enabled by default. I think
that these complexities make it harder for many people - especially
inexperienced users - who are struggling to find a simple,
understandable, predictable 1 to 1 relationship between input and
output. By this I mean "input" is what they write and do to the
computer and see on the screen and "output" is what the recipient
sees. That's why fixed width font is generally best - because you know
where you stand entirely and can use it to create carefully formatted
text, if you want.
When I write text, I don't want some program interpreting it in some
way. I want the text to be read by the person - in a fixed width font.
If my requirement was fancier, I would send HTML, Word or whatever as an
attachment.
Turning a URL into a clickable link is of course a magnificent thing -
but it does not alter the text which the person wrote.
> > For the same reason, email should default to plain text only.
>
> It does. And fighting for that costed *a lot* of time.
Thanks. A good plain-text email facility is one of the big reasons I am
looking forward to using Mozilla!
> > "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.
I went to write one, but someone spotted it in December:
http://bugzilla.mozilla.org/show_bug.cgi?id=63639
> 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.
I think "flowed" achieves something different - the ability of the
sender to have the recipient's email reader reform text according the
recipient's right margin and according to certain rules in the RFC,
which I assume are sensible. I can't imagine why I would want to use
this in any email I sent. Generally, there is no point in making more
characters per line than 72 or 77 or so. Longer lines are needed for
URLs, tabular data, or perhaps deeply quoted text. Longer lines or
ordinary prose longer than 80 chars or so are generally hard to read - I
can't imagine why I would want someone to read my prose like that.
Maybe the "flow" option could enable them to view it with a narrower
margin. That might be handy - especially if it coped gracefully with
indented text, which I think it does.
Here is the functionality I think that a plain text editor needs. It is
a basic ability to write with the user choosing whether the ends of
lines are automatically assigned, or manually defined. It enables them
to add and delete text from their ordinary paragraphs without having to
manually fuss over line endings.
If the user keeps typing and the editor wraps the text to the next line,
that is a Soft-CR.
If the user hits Enter, that is a Hard-CR.
There is a huge difference between the two. This difference should be
preserved as much as possible, until the time comes to send the email.
Then, it is sent with Hard-CRs, in exactly the same format as the user
sees on screen and on printed drafts.
Hard-CRs are intended to end paragraphs, including forcing a line end
for:
1 - Lines which are empty or have only whitespace.
2 - Indented text like this, where we don't want the editor adding
or deleting Soft-CRs because it doesn't know what the user knows:
that the spaces at the beginnings of the line . . . or anywhere
else, are a crucial part of the layout of what they are
communicating.
3 -
Any deliberately narrow paragraph
the user wishes to write, for
whatever purpose.
>From the user's point of view, soft CRs should be stored when the file
is saved. Its an ugly implementation detail that there is no way of
doing this as plain ASCII, since there is no "Soft-CR" character.
(Wordstar did soft spaces and CRs with bit 7 set high - and set it high
at the end of some words too . . . ).
I am not sure what is best. Currently, saving to a file turns all
Soft-CRs to Hard-CRs - so this is a disincentive for the user to save
and edit at a later time.
Anything else would result in a file which would produce anomalous
results unless read by the program which saved it. Maybe store soft CRs
as a distinctive ASCII pair, such as "\~" before the newline. The
number of times this would be encountered in messages would be small.
The only time this triplet would be mistaken for what the user wrote
would be if another application read the draft file. Storage is cheap,
so maybe save the newline as a word: <SoftCR> or <||> or something
really obvious to anyone who encounters it by accident, and also highly
unlikely to appear in ordinary messages. Maybe <|||||>. Bytes are
cheap!
The benefit is that the user is able to continue editing their message
with Soft-CRs intact at a later date. This removes a hidden "gotcha" of
saving the file destroying important user data - the Soft-CRs. The
programming effort in implementing this should not be great. The
benefit is for millions of users working for many years to come - being
happier with the program, not being spooked by a "gotcha" change to
their data or reluctant to save a draft. Therefore, they would finally
send a better email, and not be mucking around deleting and entering CRs
when they rewrite a paragraph where their Soft-CRs have been turned into
Hard-CRs.
I think there are several options for reforming text with soft CRs as it
is altered.
1 - Add and delete Soft-CRs as required with every keystroke. Mozilla
and N4.x do this for the initial editing session - though N4.x
has a few little anomalies at times, and Mozilla's handling of
spaces at the ends/beginnings of lines has some problems.
(This applies to typing, deletions, cut and paste and I guess for
spell-check changes.)
2 - As the old Pegasus Mail used to do, wrap to a conveniently,
numerically set and graphically indicated right margin whatever
text is currently selected, or, I think, to the end of the current
paragraph. It did a pretty good job of retaining quotes "> " to
various depths - while shortening or lengthening the ends of lines.
This is not hard to code, and is particularly helpful when the
quoted lines get too long - as they are wont to do. Pegasus did
not wrap anything automatically - so lines of any length survived
importation into the editor without any mangling. They were only
altered manually, or because of a manually activated command to
reform them.
(Wordstar 3.3 of CPM-80 ca. 1980 had variable left, right and
first-line left margins, with reform from the cursor to the end of
the paragraph - but this is over the top, although it is handy for
reforming paragraphs like these! The margins were stored in
specially marked margin lines before the paragraph. Users
could easily see and understand these - and hide them too.
Wordstar was thinking of daisywheel printers. Then the Mac, laser
printers and Postscript came along.)
3 - An approach similar to what I did in a C program in 1994 - for
getting rid of Hard-CRs within paragraphs from emails if I wanted to
convert the paragraphs into single line paragraphs suitable for
editing with Word:
a - If the line ends with a Soft-CR, ignore it in the reforming
process. (Insert a space if there was none before or after,
I think.)
b - Likewise ignore a Hard-CR, but only if the line is followed by
a line which begins with a printable character. (There was
another criteria, such as the CR being beyond column 70 or
so. This preserved short lines in specially formatted text.)
c - Keep all other Hard-CRs.
This would intelligently reform most text, but leave indented text like
the above alone. It required a bit of manual cleaning up, but that is
better than hammering away with several keystrokes for almost every line
of the email. Maybe have special rules for quoted text to let it go
longer than the wrap margin, like a long word. Unfortunately, "> " is
not universally used any more. ">" and "<< >>" etc. make quote
handling more difficult.
I think that any reform (AKA rewrap) command should operate on the
current paragraph, or from the cursor to the end of the paragraph. The
command should not work on the entire message, unless that is what the
user specifies.
Also, a reform command should not break long words, such as URLs. It
should leave such long words exactly where they are - with their end
trailing off to the right and off the screen. Word, N4.x and Mozilla
coerce the starting position on screen to the left column, perhaps
adding extra lines, but in the output file, the spaces which the user
added or left behind to the left of the long word will remain. This
discrepancy between what the user sees and what is sent should obviously
be avoided.
My tests indicate that the "Options > Rewrap" command in Mozilla simply
turns Soft-CRs into Hard-CRs - for the entire message. I don't see the
point of doing this - but I may not fully understand its function.
Now I can see why my earlier report referred to automatic rewrapping and
then to this not occurring. In the later case, I must have used the
"Rewrap" command.
I don't think any of this (apart perhaps from Wordstar's fancy margins)
is complex or non-intuitive behaviour for a plain text editor. There
*are* things people sometimes want to do with plain text - such as
selecting a rectangular block of text and copying it or moving it -
which are very simple to desire and use, but which are a lot trickier to
implement. Wordstar did this in 1980 - but I don't advocate this for an
email editor.
The wrapping behaviour I describe above is what I consider to be basic
functionality for any plain text editor which is supposed to handle both
ordinary conversational paragraphs like this one, indented paragraphs,
long URLs etc. and carefully formatted text in a tabular layout, or
ASCII art.
- Robin
