88986 - Use > instead of grey bar for format=flowed quotes, optionally

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Ben Bucksch (:BenB)]

Some kind of people don't like the HTML-like grey bars that we use to mark
quotes in plaintext. They prefer the old style of ">" in front of each line.

Now, that's not easy to realize. We'd basically need a CSS-pseudo-element
:before-each-line. There was a discussion about that around Jan 2001 on
.mail-news / .css.

Implement a backend-pref to use ">"s instead of bars.

Note that this is a display style only, it does not mean disabling format=flowed
altogether. I.e. if the window is too small to display 72 chars/line, it would
still display (correct) smooth wrapping, not long-short-long lines like it does
for normal plaintext.

We already have a backend-pref to disable the bars for normal plaintext. Maybe
also add a UI pref to set both of these prefs at once, e.g. "Mark quotes [in
plaintext] with > instead of grey bar".
(We current don't have a UI pref for disabling bars in normal plaintext, because
it is almost impossible to explain the difference between format=flowed and
normal plaintext to the enduser.)

Comment 1

[Robin Whittle]

Email clients should by default support plain text communication, where every 
single character the sender writes, including the exact position of each 
character, is reproduced precisely, without adornment, to the recipient, 
exactly as the sender saw on his or her screen when they wrote it.

To disagree with this is to have a fascist attitude to how other people 
communicate.  IT is to say that the automagic, nifty, alterations to messages 
you like should be forced on everyone.  Its not good enough to say that HTML 
should be the basic mode, because not everyone's clients or mailing list 
archives can display HTML, and there are all sorts of problems with fonts, 
layout etc. which can be different for the recipient and unknown to the sender.

Some of the most perplexing problems with computers for experts and novices 
alike are the hidden gotchas.  Its vital that these be eliminated, especially 
with email, where the person sends a message with the reasonable expectation 
that the recipient will see exactly what they saw before they sent it.

For this reason, HTML should *not* be the default mode of composing messages for 
email or Usenet.  HTML email is a can of worms and should only be used by 
senders when they have a good reason, when they are aware of the difficulties 
they may be causing for the recipients.  This is especially true when people are 
writing to mailing lists, which affect hundreds of people, and where HTML cannot 
always be displayed properly to recipients, or archived, or integrated into a 
digest.  http://www.firstpr.com.au/sys-admin/HTML-email/

  
Format-flowed is a good example of something which is potentially useful which 
can alter the layout of the message as seen by the recipient, without the sender 
ever knowing.  Sometimes, the layout of the message is important - its not just 
a cosmetic matter.  Even if it was "cosmetic", there is no reason why "cosmetic" 
alterations should be forced on everyone by default?   I think that some 
programmers and HTML fans draw unrealistic distinctions between the "content" of 
 a message and its formatting.  Sometimes, the formatting is a vital part of the 
content - such as when writing tables of text, diagrams, poetry etc., and so 
this should never be altered by default arrangements by either the sending or 
recieving software.

Format=flowed should be off by default when sending messages, and its 
interpretation when displaying them should be off by default.  See Bug 86607.

Likewise the substitution of graphics for ":)" etc.

Likewise the bolding of *things* like this.

Likewise these damn bars for "> ".  Even if such a system is adopted, how can it 
reliably decide how best to display things like:

>  Blah
>> blah
> >blah
>>>blah
  
without upsetting the horizontal alignment of the text, which may well be an 
important part of what the sender is communicating?

It could also confuses a recipient who wants to select and copy the text - 
because they don't want bars, since bars are not part of text.   

I recall there is some fancy algorithm for handling one or more "> " characters 
when expanding lines with format=flowed.  It can easily be imagined that this 
would upset the senders intentions on some occasions.  

Also, many people are slack when responding to quoted text.  They do not always 
put their responses on a separate line.  This is their problem, but I can 
imagine that the bar system makes it harder to see, since it implies a linkage 
between multiple lines which began with "> ".  The easiest way the recipient can 
read and untangle a message which is not very well written is to see it in its 
raw, unaltered, state, not with extra interpretations put on it by automagic bar 
or format-flowed display software.

The bar thing is purely decorative anyway.  I don't see the attraction of it at 
all.


All these "features" are valuable for some people, but they should be off by 
default and easily enabled by the user, not just be putting things in 
preferences files.


It should not be necessary to demonstrate circumstances when such unwanted by 
the sender, unseen by the sender, manglings of their message are likely to be a 
problem.  Why should people have to argue for leaving messages alone?  There's 
no good reason.    

If we want super-fancy automagic things popping up and doing smarty-pants 
nifties by default, we will use software from the Evil Empire.


 - Robin Whittle     http://www.firstpr.com.au

Comment 2

[Ben Bucksch (:BenB)]

Robin Whittle, your political statements about me being a facist and your
arguments are totally offtopic here, apart from being wrong. Please search on
netscape.public.mozilla.mail-news for posts by me, we had extensive discussions
about that.

Comment 3

[Daniel Bratell]

Robin, I think you are looking for the telnet/cat MUA. It supports most if not
all of what you desire.

And I want to make one point clear, Mozilla doesn't default to HTML mail. I
don't think it ever has, and it won't change any time soon.

Comment 4

[Robin Whittle]

Daniel, Mozilla defaults to the HTML composer for mail.  It always has in my 
experience, and to prove the point, I just downloaded 1.2B and installed it on a 
Win2k machine which has never had any version of Netscape or Mozilla installed, 
so there would be no effects from previous profiles etc.

Perhaps you are referring to "Send Format", as set in Edit > Preferences > Mail 
& News.  This defaults to "Ask me what to do (Mail prompts you to choose a 
format)".   If the user chooses to send "text only", for each message, or by 
choosing the option there of "Convert the message to plain text (some formatting 
 may be lost)" then they are writing their messages in the HTML way, with a 
proportionally spaced font, layout, line lengths and potentially colours, 
italics etc. which will never make it to the recipient.  If they attempt to add 
spaces etc. to get the layout they want, such as indenting, these will almost 
certainly be shuffled into different lines and the result will be a mess.  
Furthermore, this transformation of the message will not be visible to the user 
- only to the recipient.  So this arrangement of throwing people by default into 
the HTML composer and then stripping it back to "plain text" is a prime example 
of what I am saying Mozilla should never to do.   

By default, Mozilla and any other decent email program, should enable people to 
write in plain text, fixed width font, so that every character they type, in its 
exact position as they see on screen, is conveyed to the recipient without any 
alteration.  Furthermore, when displaying such a message, the software should 
display it verbatim, without bolding, graphic smilies, vertical bars or 
whatever.   This is what email programs have always done, since before the days 
of GUIs - since the days of terminals and Telnet.  The reason I say this basic, 
untransformed, text-only functionality should be preserved is that it is the 
only sure way of communicating something to another person without 
transformations, unless you want to get into PDF files and the like.  (HTML 
could be used too, if you understood it and could be sure the other person could 
render it correctly.)  We can reliably assume that everyone has, or should have, 
a basic ability to read plain text emails.  We can't assume they can handle HTML 
or PDFs or Word documents etc.

Assuming, as is reasonable, that the receiving client can display and print to 
80 characters or so, and that the sending client automatically wraps the text 
visibly on screen to 72 or so by default, then this enables anyone to send an 
email to anyone else, (not counting questions of non-English fonts) with 
certainty that the message will be conveyed without any "enhancement" / 
transformation / mangling. 

It is vital that this be the default, so new users have an experience of 
something simple and not subject to hidden transformations.   Its not so much 
the complexity of computers which is a pain, but the way they can bite - with 
hidden gotchas and unwanted results which cannot be corrected once they happen.  
Sending an email to someone and having its layout altered by the sending or 
receiving client is a good example of a gotcha which cannot be corrected.  Worse 
still, it disrupts communication between two people.

I am perplexed that this is not obvious to everyone, and that over the years I 
and other people have had to argue for Mozilla achieving this basic, clear, 
totally-compatible with all other email clients, set of goals.  Its not complex 
to do this, but for some reason, there are people associated with the Mozilla 
project who think that HTML should be the default method of composing emails, 
and that various transformations should be made at the receiving end which are 
not visible to the sender, such as these vertical bars.   HTML and these display 
"enhancements" are all fine - I am just arguing they should be off by default.

Your facetious tone in telling us that you think I am looking for a Telnet 
client does not help anyone.   I want what everyone else wants - a fabulous 
browser, email/Usenet client and HTML composer all in one!  I have put a lot of 
effort into reporting bugs and this has been appreciated by at least one Mozilla 
developer.  I get really frustrated at people arguing for default-on 
"enhancements" which have the effect of disrupting people's best (default) 
attempts to send a message so the recipient sees precisely what the sender 
wrote.

I get particularly frustrated with Ben Bucksch stating in public that I am 
spamming Mozilla's Bugzilla, that I am talking politics, or that I called him a 
fascist.   I did no such thing.  I am not discussing politics - my use of the 
term "fascist" was to prompt people into reconsidering that their view that 
particular "enhancements" such as default-on format=flowed (which has the effect 
of altering the layout of a message seen by the recipient, unbeknownst to the 
sender) should be foisted on millions of future Mozilla users, just because they 
personally think it is a good thing.

I wasn't thinking of anyone in particular - I was not referring to people.  I 
was referring to an attitude which I do believe has elements of fascism:  
"Millions of people will have their emails transformed as a result of using this 
software because I think it is a good idea, or because I consider such changes 
to be of no consequence to thos people.  Furthermore, this will happen without 
their active choice and often without their knowledge."

Ben, if I thought you were a fascist, I would say so.  If I wanted to create a 
fuss or vilify anyone, I would do a better job.

  - Robin

Comment 5

[Garth Wallace]

rw: this bug is for adding an option to use the > character for quotes in
format=flowed messages. That's it. It's not for changing defaults *at all*...if
you want to have the defaults changed, open a new bug for that. One bug = one
issue. Thank you and goodnight.

Comment 6

[Daniel Bratell]

Yes, the composer with access to formatting is the default (the one you call
"HTML composer") but that has nothing to do with the format of the sent mail. If
you want a debate, which you clearly want, you should use the newsgroups.
Cut'n'pasting political and insulting statements into a number of bug reports is
just plain wrong. Please go to the newsgroups with it instead if you really have
the need to express your opinion in public.

Comment 7

[R.L. Olive]

This is my first post in Bugzilla.  I came here to say that I can not find a
preference to turn off the gray bars that are being used to replace the '>'
character.  To me, this is an assumption that I have a problem with.  I often
get code diffs emailed to me, and the mail viewer incorrectly replaces the '>'
with a gray bar.  Here is an example of what is sent to me:

-----[104 changed to 103]-----
<       container.setLayout(gbl);
---

>       container.setLayout (new GridBagLayout());


But what I see displayed is:

-----[104 changed to 103]-----
<       container.setLayout(gbl);
---

|       container.setLayout (new GridBagLayout());


In the context of diff, this makes no sense.  If I look at the message source
(ctrl-U) I see that the message looks OK.  So I should have a preference in:
   Preferences Window:
      Mail & Newsgroups
         Message Display

   When viewing plain text message:
      x Wrap text to fit window width
      x Display emoticons as graphics
      o Convert > to | for quoted messages  (this is the new one)

I believe it should be off by default, but I don't care as long as I can turn it
off.

Comment 8

[Robin Whittle]

Like graphic smilies and sending with "format=flowed" someone 
put a lot of effort into implementing this "vertical bar" 
feature - but to me and many other people, its a mis-feature.


Feature          Default       GUI?       user.js

Smilies          On            Yes        I guess so

ff send          On                       Yes

ff read          On                       Yes

V-bars           On            


Please, whoever wrote this, at least give us a user.js way of 
turning it off.

I believe that all these features have valid uses, but they 
can be a problem to many people, so they should be off by 
default - and have a user interface option to control them.  

I don't want to debate how many people it is a problem for. 
Mozilla has, or should have, a user base of millions of 
people and if even a handful of them find the new "feature"
a problem, or make it impossible for them to use the 
program, then it should at least have a user interface option
to turn it off.

Now, with bug 141983 shown to be caused by sending with 
"format=flowed", and with this being disabled via user.js,
this display and printing of vertical bars is the only 
remaining barrier I know of to achieving proper, basic, 
transparent, plain-text email on Mozilla.  

Below are two separate bugs which appear to be related to the 
vertical bar code.  I report these in the context of this bug 
- to argue for the vertical bar to at least have a user option 
to turn it off, and preferably for it to be off by default.

Someone else who cares about vertical bars may want to take these
problems and make them into proper bugs if they are not already
recognised as such.

If I send this in a plain text, non- "format=flowed" message, 
from N4.77:


V-bar test
> Mozilla is an open-source web browser and toolkit, designed for 
standards 
> compliance, performance and portability. Mozilla.org provides 
> binaries for testing and feedback. For more about mozilla.org, 
> read Mozilla at a Glance.


where this is six lines, each with a newline, then Mozilla's 
(2003050211) vertical bar "feature" makes it appear like this 
on-screen or when printing:


V-bar test
| Mozilla is an open-source web browser and toolkit, designed for 
standards 
| compliance, performance and portability. Mozilla.org provides 
| binaries for testing and feedback. For more about mozilla.org, 
| read Mozilla at a Glance.


Netscape 7.02 does the same.

But when I select this text for copy and paste, this is what I 
get, for Netscape 7.02:


V-bar test

> Mozilla is an open-source web browser and toolkit, designed for 

standards 

> compliance, performance and portability. Mozilla.org provides 
> binaries for testing and feedback. For more about mozilla.org, 
> read Mozilla at a Glance.


There are three erroneous blank lines in this.  So its not just 
an aesthetic and readability problem.  Something - presumably this 
vertical bar code - is messing up the user's ability to do basic 
things like copy and paste.

When I do the same with Mozilla 2003050211 a second bug becomes
apparent: doubled quote characters.


V-bar test

>> Mozilla is an open-source web browser and toolkit, designed for 

standards 

>> compliance, performance and portability. Mozilla.org provides 
>> binaries for testing and feedback. For more about mozilla.org, 
>> read Mozilla at a Glance.



There should be a principle that all these extra "features" - 
which may be nifty and useful, but which are designed to alter
the message or its appearance, and so prevent straightforward 
conveyance of the sender's message - should be Off by default.

The first reason is obvious - altering the message will, for
some people, disrupt communications.

The second reason is that these "features" all involve
additional code in themselves, as well as extra complexity
in the code they are embedded in - and so involve a greater 
risk of bugs in their operation, and in unwanted side-effects 
in other places, than no code at all.  Since it is evident 
that those who write these features don't alwys do simple 
tests of copy and paste (as far as I know, maybe there is
a bug for these things already), then it is not good 
enough to assume that the new feature is bug-free.  

There needs to be very strong arguments for any such feature
being on by default in a functional piece of software like
Mozilla which millions of people depend upon for a wide 
range of serious and crucial purposes - and vertical bars 
and smilies are purely decorative.


  - Robin

Comment 9

[Ben Bucksch (:BenB)]

Robin, bugzilla is primarily for technical discussion, not advocacy. You wrote
more than 50% of this bug's length, without adding *anything* useful to it.

> to argue for the vertical bar to at least have a user option 
> to turn it off, and preferably for it to be off by default.

You don't need to argue for that, I think we all agree that the user should have
*some* way to disable the bars. What we need is somebody *implementing* it. Will
you?

> If I send this in a plain text, non- "format=flowed" message, 

This is offtopic. You already do have the ability (in user.js) to disable the
quote recognizer (and with it the vertical bars) for real plaintext, exactly
because it's just a recognizer and ambiguous.

> There should be a principle that all these extra "features" - 
> which may be nifty and useful, but which are designed to alter
> the message or its appearance, and so prevent straightforward 
> conveyance of the sender's message

Wrong. f=f *unambiguously* marks quotes, there is no alteration involved, we
exactly represent what is sent to us. And it is completely up to the user agent
how to reprepsent that / display them. You grew up with > as quote marks, that's
why you prefer them. Most people today grew up with vertical bars as quote marks
due to HTML, and that's why they prefer them, and also because they have (IMHO)
clear objective advantages.

I understand that you are old-school and prefer to see >s. That's what this bug
is for.

> The second reason is that these "features" all involve
> additional code in themselves, as well as extra complexity
> in the code they are embedded in - and so involve a greater
> risk of bugs in their operation, and in unwanted side-effects
> in other places, than no code at all.

In fact, vertical bars for f=f not just give a better result (IMHO), but the
implementation is *far* easier. Implementing *this* bug (no matter, if we allow
vertical bars or not) will be a new feature, and a considerably complex one at
that. You just argued to wontfix this RFE.

> vertical bars and smilies are purely decorative.

And a selling feature for the masses (but that's not the only reason why I added
the vertical bars).

Comment 10

[Ben Bucksch (:BenB)]

> a considerably complex one at that

To emphasise this: If it was easy, it would have long been implemented by now.
We don't have it yet, because it is so hard and considerably messes up the
surrounding code or even requires new features in Gecko.

Comment 11

[Robin Whittle]

Ben, you wrote:

> You don't need to argue for that, I think we all agree that the
> user should have *some* way to disable the bars. What we need
> is somebody *implementing* it. Will you?

I had not realised that this was agreed.  I assumed it wasn't yet
established that it should have a UI option.   Is this the view of others?

My one attempt at delving into the Mozilla code involved a week of
work, reading the doco, figuring out how to compile it on Linux and
Windows, trying to understand a very large body of stuff - and in the
end I didn't achieve anything.  jfrancis later sorted out the problem.
I guess it would have taken me weeks to get up to speed with something
that he, and perhaps others, was already much more familiar with.

I figure that whoever wrote this vertical bar code is reading this bug
and that they could provide a way of turning it off far faster and with
less chance of making a mess of it than I could.

> > If I send this in a plain text, non- "format=flowed" message,
>
> This is offtopic.

It is not off topic.  I get really annoyed at your persistent attempts
to suggest that I shouldn't write what I do.  It has a chilling effect
on the debate for people to see you do this - it makes them less
inclined to contribute for fear of getting the same criticism that I get.

It is on topic because I need to explain the nature of the email I sent.
 As far as I know, whether or not it has "format=flowed" in the headers
will affect how Mozilla / Netscape decodes it, so I need to state this.


> You already do have the ability (in user.js) to disable the
> quote recognizer (and with it the vertical bars) for real plaintext,
> exactly because it's just a recognizer and ambiguous.

I didn't know this.  This is what I am asking for: a way of turning off
the vertical bars and any other fancy processing.  Yet you just said
that we all want a way of turning it off, and that no-one has done it yet.

I read this bug carefully and I saw no mention of how to turn them off.
How do you do it?


> > There should be a principle that all these extra "features" -
> > which may be nifty and useful, but which are designed to alter
> > the message or its appearance, and so prevent straightforward
> > conveyance of the sender's message - should be Off by default.
                                       ===========================

   (Underlined text was not in what you quoted.)

> Wrong. f=f *unambiguously* marks quotes, there is no alteration
> involved, we exactly represent what is sent to us. And it is
> completely up to the user agent how to reprepsent that / display them.
> You grew up with > as quote marks, that's why you prefer them. Most
> people today grew up with vertical bars as quote marks due to HTML,
> and that's why they prefer them, and also because they have (IMHO)
> clear objective advantages.

You disagree entirely with the principle I propose but what you write
after that has nothing to do with the principle.

What you write is about your interpretation of one of the instances in
Mozilla where I believe this principle has been violated: sending with
"format=flowed".

It is beyond question that sending with "format=flowed" alters the
message.  It may well be that a compatible reader can reconstitute it,
but the message is altered for all other recipients.

This is a perfect instance of the principle being broken.

What you seem to be arguing is not against my principle, but a counter
argument to the idea that "format=flowed" is contrary to my principle.
Your argument seems to be that a quote is still encoded explicitly in a
message sent with "format=flowed", and it is up to the recipient user
agent whether the message will be displayed as it was originally written
or in some other way.

The question is not what happens when the message is read by a
"format=flowed" user agent.  The question is what happens when a message
sent with "format=flowed" is not interpreted by such an agent.  My
argument is that sending with "format=flowed" changes the message in a
whole variety of real-world situations where the message is not decoded
by a "format=flowed" algorithm.  Therefore, sending with "format=flowed"
is an instance of changing the message.  Therefore it is at odds with my
principle.

Do you really disagree with my principle?   If so, they I guess you
would argue for this:

   Extra features which are designed to alter the message or
   its appearance and which may be useful or nifty need not -
   or should not - be Off by default.

This seems to be the principle on which you or others have implemented:

 Graphic smilies instead of :) etc.
 Sending with "format=flowed".
 Receiving with "format=flowed".
 Grey vertical bars instead of ">" near the start of the line.


It is irrelevant how particular people conceive of quotes or how they
prefer to see them on screen or on paper.

The principle is that by turning a line which starts with one or more
">" characters into a vertical bar you change it.  A vertical bar is not
a ">".  You might think it means the same thing, but that is your view -
not mine and not other people's.   If you like it this way, that's fine.
 The point I make time and again, because you keep avoiding it, is that
this and the other things I listed are default-On "features" which alter
the message which is sent and/or the way it appears on screen and on paper.

Also, as I demonstrated, it alters it when the screen representation is
selected and copied to the clipboard.

That is why it should be Off by default, unless you disagree with my
principle.


> I understand that you are old-school and prefer to see >s. That's
> what this bug is for.

It is a bug for anyone who wants straightforward communications
unaltered by algorithms which do not appeal to them.

> In fact, vertical bars for f=f not just give a better result
> (IMHO), but the implementation is *far* easier.

I don't believe you.  The task is to display a bunch of text, broken
into lines which may be longer than the screen and which should not be
displayed if they go beyond the right limit (unless there is a wrap
function enabled).  Its a very straightforward task.  All you do is
whatever you already do, except treat ">" characters near the left
margin just the same as any other character.


> Implementing *this* bug (no matter, if we allow vertical bars or
> not) will be a new feature, and a considerably complex one at
> that. You just argued to wontfix this RFE.

This would only be true if the current code was abysmally written.

Can you point me to where this code is?

I reckon I could find one or more byte comparisons with ">" and AND them
with a user preference.  In what way would this either not work or be
complex?


> > vertical bars and smilies are purely decorative.
>
> And a selling feature for the masses (but that's not the only
> reason why I added the vertical bars).

Ahh - you wrote this stuff! Why did you write it without a user preference?

Why did you write it default on?

Why did you write it so that, as you say, it is more complex to turn it
off than it is to implement it the first place?

I think that "a selling feature for the masses" is a reliable tool which
is easy to understand, has no extraneous "features" on by default, and
is therefore extremely easy to use.


> > a considerably complex one at that
>
> To emphasise this: If it was easy, it would have long been
> implemented by now. We don't have it yet, because it is so hard
> and considerably messes up the surrounding code or even requires
> new features in Gecko.

How on Earth did you make such a mess of it?  You have perfectly good
code in Gecko for displaying arbitrary text in fixed width fonts in the
preformatted mode of HTML.  I imagine that plain text message display 
should use something like that - something pre-existing which does the 
job.

If you want to reflow or wrap the text, do so before using that
preformatted method on it.

If you want to display with vertical bars, create another method to do 
this.


I think you are mistaken to assume that all lines which start with a
">" are lines in which all human readers want to see this character
operate as a quote.

By failing to distinguish between the actuality of a physical ">" -
which is the only thing which can do the job of a ">" for all possible
uses of the message (for instance copy and paste to a digital signature
checker, or any other technical or ASCII diagram usage) - and your own
private conception of a ">" at the start of the line - which is that it
always represents a quote - you have made Mozilla force all messages 
into interpretation according to your particular ideas, rather than 
leaving the message as it was.

What about the two bugs in select and copy I pointed out?  This is your
code and it fails to achieve basic select and copy functionality.

  - Robin

Comment 12

[Ben Bucksch (:BenB)]

> I assumed it wasn't yet established that it should have a UI option.

I didn't say anything about a *UI* option, but I don't oppose it either.

> > You already do have the ability (in user.js) to disable the
> > quote recognizer (and with it the vertical bars) for real plaintext,
> > exactly because it's just a recognizer and ambiguous.

> I didn't know this.  This is what I am asking for: a way of turning off
> the vertical bars and any other fancy processing.  Yet you just said
> that we all want a way of turning it off, and that no-one has done it yet.

*sigh* I said "real plaintext". This bug is about f=f. Completely different
implementation. You can turn the quotebars off for real plaintext, but not yet
for f=f.

BTW, this is also what I said in the initial description of this bug: "We
already have a backend-pref to disable the bars for normal plaintext."

As for how to do it, <http://www.hmetzger.de/etips6.html#34>.

> That is why it should be Off by default

Again, offtopic. This bug is about implementing this particular feature.

> > vertical bars for f=f [...] the implementation is *far* easier.

> I don't believe you

OK, let's stop that. It's starting to get silly.

> Can you point me to where this code is?

mimetpfl.cpp

> In what way would this either not work or be complex?

It doesn't rewrap with quote markers on every line, and with smaller windows,
you get the same terrible "comb" quoting (one line appears quoted and one or
more lines appear unquoted, interleaved) that you get with plaintext. You could
just as well completely disable f=f, then, for which we already do have a pref.

> Why did you write it without a user preference?

I did!

> Why did you write it so that, as you say, it is more complex to turn it
> off than it is to implement it the first place?

I wrote it for real plaintext, not f=f.

> How on Earth did you make such a mess of it?

OK. Great. If you think that Mozilla is such a mess, how about using another
mailer? I think we'd both be happier with that. May I suggest mailx? Or write
your own?

> By failing to distinguish between the actuality of a physical ">" ...
> and ... that it always represents a quote

You're talking about plaintext here. With f=f, we *know* what is a quote and
what was a > at the beginning of a line.

Comment 13

[Robin Whittle]

Ben, you wrote:

> BTW, this is also what I said in the initial description of this bug: 
> "We already have a backend-pref to disable the bars for normal plaintext."
> 
> As for how to do it, <http://www.hmetzger.de/etips6.html#34>.

OK - I misunderstood the scope of this bug in not realising it applied 
only to "format=flowed" messages.  I apologise for not recognising 
this.   I can see that the code for rendering "format=flowed" would be 
totally different from the straightforward text display code I was 
thinking of.  That is why I could not understand why you said it was 
complicated.  Sorry about my criticisms which resulted from my 
misunderstanding.

Thanks for the URL for the user.js codes.  I will read that page 
fully - and others at that site.

 - Robin

Comment 14

[Jerry Baker]

This should probably be changed to reflect the fact that Thunderbird now exists,
but I can't find a component for it under Core. Ben?