Robin Whittle wrote:
> My reports on these newsgroups (I hope it right to post to both)
Yes, it is.
> In November, I did at least a week of *intense* work trying to
> characterize whitespace bugs in Composer.
[...]
> 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.
Don't you think, I have the same problem? Can you imaging how it bugged
me to use a browser for months which couldn't even file bookmarks while
adding them, resulting in a bookmark menu with 200 entires at the top level?
Coding resources ("programmers") are very limited in this project,
unfortunately.
>>> 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!
Some "look into the future":
<http://www.beonex.de/download/mozilla/mozilla-20010305-threadpaneperf.tar.bz2>
(Linux).
>>> 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.
Tried Mozilla 0.8?
> 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.
IC.
> 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:
I once worked on that, but it never manifestated.
You can basically do that. Reply (in HTML or plaintext), hack your
comments in, save as draft, move the draft from the drafts folder to the
topic folder. In threaded view, the commented "mail" will appear under
the original.
> 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.
huh? Create a folder, move the mails there. I have folders for different
topic, and I manually sort mail, regardless if sent or recieved, there.
So, I have mails sorted by topic. Use "threaded" view to sort for
individual corrspondences. Assuming decent mailers, you have them sorted
in a very convient tree (IMO better thant linear).
> 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.
Mails are be sorted after UTC (Greenwich), not the local time, so
everything should work fine, assuming the mailers/OSes are configured
correctly.
> Ideally, there needs to be a way of searching the correspondence - both
> received and sent emails in one search.
Possible, see above.
> 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.
You have to print manually. So you can sort (copy/move to "topic
folders") manually.
> 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.
Do you have any idea, when paper letter management costs. (Of course, no
excuse: We can do better, and this is the reason why the Internet flies.)
> 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.
We discussed long time about that. See the archive of this very group.
The solution was to have Preferences (in the UI).
> 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.
Note: The smily-interpretation is a facility of the *recieving* program,
not the sending one. Similar for format=flowed (it will look like normal
plaintext for older mailers). The recipient can do what he likes with
your mail (privately). *I* like the recognition, so I read *your* mail
with recog. turned on. You don't like the recognition, so you read my
mail with no recognition. That's the idea of sending as plaintext, while
doing fancy recognition at the recipient side. Where's the problem?
> Turning a URL into a clickable link is of course a magnificent thing -
> but it does not alter the text which the person wrote.
It does. It changes the color. I had people arguing that they didn't
want it. Bottom line: It's all a matter of taste and how far you want to
go. No "right thing" here.
>> 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
You need to store the draft in some format. In which one? If you save in
normal plaintext, soft-crs are lost, because plaintext doesn't know
them. So, we have to save in either HTML (which we do for the HTML
editor) or format=flowed (which we do for the plaintext editor).
Clearly, 'not all text is made equal' :-).
> 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
For *you*.
> I
> can't imagine why I would want someone to read my prose like that.
I can. I want to.
> Maybe the "flow" option could enable them to view it with a narrower
> margin.
Right, for example.
> 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.
That's how it works in Mozilla (at least in the HTML editor, which can
send as Plaintext - I don't use the plaintext editor),
> 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.
See, nor all people share your favor for Plaintext. I don't want to read
or wrote text with a 80-char limit. I compose in the HTML editor, which
wraps to the window with, and send as plaintext. Ideally, my
correspondents send format=flowed, so I can read flowed as well.
This is the standard for Mozilla. To be honest, the plaintext editor
doesn't get much work - be happy to have it at all. I guess, if some
Netscapers (most akk I presume - wave :-) ) didn't fight for it,
Netscape would have cutted it.
If you like the Plaintext editor, but think, it needs improvement, hack
it or fudn someone to hack it. I know, that sounds hard, considering how
much time you spent debugging it, but it is the reality - everything
needs funding. Netscape doesn't care too much. So, *anybody* has to step
up and do it himself. I won't be it.
> >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.
That's exactly what I tried to say.
> I am not sure what is best. Currently, saving to a file turns all
> Soft-CRs to Hard-CRs
Ah, I guess, I know what's going on. Not saving, but *opening* the mail
loses the soft-CRs - the plaintext editor interprets it as normal
plaintext. Daniel Bratell, any idea?
> 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.
This is exactly what format=flowed, is, just better :-).
> The
> benefit is for millions of users working for many years to come - being
> happier with the program
I think, you're getting the numbers wrong here. There aren't millions of
Mozilla Plaintext Editor users, and there might never be.
Most use the HTML editor, which works fine in this case.
> 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.
Almost everything we do here might result in a "people might send better
email", just in different amounts. I agree with you, it is a bug, you
just lose the big picture.
> It did a pretty good job of retaining quotes "> " to
> various depths - while shortening or lengthening the ends of lines.
We can do that, too, with the HTML editor. Just switch to "Body" (not
"Preformatted").
> This is not hard to code
It is hard to fight the people which complain "Don't mess with the quotes".
> They were only
> altered manually, or because of a manually activated command to
> reform them.
Exactly how the HTML editor works.
> 3 - An approach similar to what I did in a C program in 1994
oh, you can code? Cool, get on board and hack Mozilla!
> 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.)
This is a "paragraph recognizer" (which is a very fancy type of
recognizer, guessing *a lot*). Compare bug 46993.
> This would intelligently
hah
> 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.
> 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.
It is a primitive function. Nobody has time to improve it.
