Robin Whittle writes:
> No spell check.
It works in the Netscape branded version, but unfortunately the
company who owns the spellchecker code wouldn't agree to release
their source. We've been asking for years for someone to do the
(fairly minimal) work it would take to plug an open-source spell
checker into mozilla's editor hooks.
> 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,
We could do this. We already know how to save as flowed (it's a
flag in the output system, used by mail when sending format=flowed).
All that would be needed is a way to read in a plaintext message
as format=flowed, ignoring the space-newline sequence instead of
preserving the newline so that it gets turned into a <br> in the
editor. Mail obviously already has code to do the interpretation,
or we wouldn't be able to display f=f mail correctly. Running it
on reading in a message from a folder should be very easy, I would
think. If it doesn't do this correctly, you should file a bug.
(Probably to mail/news, but cc me in case someone can argue that
the editor might also need this functionality.)
> The impossibility of opening a new mail folder in a new window is
> driving me nuts. Right clicking is no help - that just turns the
> current window into the right-clicked mail folder. So the only way of
> opening another mail folder is to make the current window and the new
> one open in the new folder (each taking its own time to do this) and
> then manually change one of them back to the original mail folder.
I agree, it's a real usability blocker in mail. Vote for bug 35389.
> This is intolerable. Corruption of user data and false display of user
> and received data means the user cannot communicate reliably with other
> people.
I agree with you. Here's why this happens: The Netscape emphasis has
been on html mail, for good or ill. (If it's wrong, no one has managed
to convince them why plaintext mail should be an important corporate
goal). This means that plaintext work for developers inside
Netscape is a spare-time thing (and there are only a few of us who
care enough). This also means that QA doesn't test plaintext mail
much -- e.g. it's not a regular part of the daily acceptance tests.
So to get plaintext mail working solidly, we either need someone to
convince Netscape that it should be an important corporate goal (and
rest assured you're not going to do that by posting to these lists,
since the people you'd need to convince don't read developer groups)
or get non-Netscape resources to pitch in and make it better.
We're dependant upon people like BenB (and also Daniel Brattell
and others) who have made plaintext mail infinitely better than it
otherwise would have been. And you, Robin -- the bugs you've filed
really are a help, and I wish you had time to do more.
Incidentally, one BIG help would be someone to write automated JS
tests. If someone could write a test harness that basically brought
up a mail compose window, read in a message (or replied to it),
did some editor operations then wrote the message out, then we
could have all kinds of automated regression tests, which would
make it much more worthwhile to put work into fixing some of these
problems.
> 2 - Lack of appreciation for the value of plain text - based on
> some view that "complex and flexible = better" and therefore
[ ... ]
> 4 - The fact that some people write really sloppily anyway -
I think these two points are why the corporate emphasis is on html.
The argument is that few people care about the sort of precision
you mention. Alas, the argument is probably correct, much as
we might wish otherwise.
> The work of adding an email/news-specific plain text editor with the
> correct behaviour to Mozilla seems daunting, since the editor doesn't
> work on text at all - but on the data as abstracted into complex linked
> data-structures by the layout code. Also, there would have to be work
> on the code which reads files into the data structure and writes them
I don't think it's really that bad. I think our current plaintext
editor is close. Fix the whitespace bugs (I just asked Joe, he says
he's close to a fix for most of them) and write something to read in
a flowed document and not put breaks where the soft newlines are
(should be very easy) and we're pretty close to there, no?
> 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.
It should work that way now. In the plaintext editor, text is
displayed with a style that specifies preformatted with wrapping
at the appropriate column. No newlines need be inserted; the style
system does the wrapping as long as we stay in the editor. If the
user hits return, then we insert a <br>. That's a hard newline.
At output time, in the flowed case, AFAIK soft newlines (" \n")
are only inserted when we wrap long lines, i.e. lines which in the
editor window were wrapped by the style system. If we see a <br>,
we output a hard newline (no space preceding it). All very
consistent, and easy for a read-back-in routine to deal with.
> 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.
It may be that mail has a bug that it only sets the flowed flag
when it sends mail, but not when it writes to a folder. If so,
you should file that bug. Certainly soft returns are retained
when writing to the SMTP server, or f=f wouldn't work at all.
Of course, if you use plaintext and turn off f=f, you won't get
soft newlines, because plaintext without f=f doesn't HAVE such a
concept ...
> 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.
Our model is generally that commands work on the selection.
I think rewrap applies to the whole document if the selection is
collapsed.
> Also, a reform command should not break long words, such as URLs. It
Absolutely agreed. URL breaking (like Eudora and Mac OE) is evil.
> 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.
The whole point of the rewrap command is that you have a message
which was hard-wrapped to the wrong width, and you want to rewrap
it to a reasonable width. If the message had soft CRs, you wouldn't
need to rewrap it, it would already be displaying correctly.
You might argue that Rewrap should actually be Unwrap, i.e. it
should remove all <br> tags and let the style and output systems do
their normal things. In the case of original text, you'd be right
-- please file a bug on that and assign it to me -- but in the case
of quoted text, we have to use hard line breaks because each line
starts with one or more ">" characters, and if we let the style
system handle the wrapping, those quote characters wouldn't be at
the beginnings of the line any more.
Now, we could solve that the way the message display window does --
use <blockquote type=cite> or whatever instead of > characters --
but then it wouldn't be a plaintext editor any more, we'd have to
add blockquote-handling rules to our plaintext editing rules, and
people who prefer to have exact control over their message (which
is true of most people who use plaintext mail compose) would get
upset at us and flame about why they were seeing html in their
supposedly plaintext compose window.
...Akkana
