<<< Date Index >>>     <<< Thread Index >>>

Re: [PATCH] fix indent_string handling with format=flowed



Hi,

* Johannes Stezenbach [07-10-16 14:54:05 +0200] wrote:
On Tue, Oct 16, 2007, Rocco Rutte wrote:
* Johannes Stezenbach [07-10-15 23:46:23 +0200] wrote:

2. reply to a format=fixed mail: just add '> ', not '>'
  (sub optimal but IMHO correct according to RFC 3676 -- since
  the lines are fixed they cannot be reflowed anyway and it
  doesn't really matter if it is '>> foo' or '> > foo', and
  the latter will look better in plain old MUAs)

First, as $text_flowed ist set, '> > foo'-style quoting is wrong while '>> foo' is okay. It doesn't really matter whether the line is fixed or not, it's a line of a f=f message with a quotelevel of 2, hence either '>>foo' or '>> foo'.

I beg to differ: The quote depth as defined in RFC 3676 has only
significance wrt to reformatting of quoted lines. If a quoted line is
as fixed line (or a series of fixed lines, i.e. not a paragraph in
as defined by RFC 3676), then it is totally irrelevant if it is
'>> foo' ('foo' with a quote depth of two) of '> > foo' ('> foo'
with a quote depth of one). The quote depth just has no meaning
for fixed lines.

Only regarding flowing: yes. For all other aspects: no.

In a f=f message some f=f aware client has to determine the quote level before even looking at whether the line is fixed or flowed, including logical deletion of these quote levels (still before even knowing the line is fixed). E.g. when you have a client that can hide and show individual quoting levels, it won't recognize three fixed lines '>> Foo', '> > Foo' and '>> Foo' as all being quote level 2.

Also, quote level detection is important for properly coloring quote levels which mutt strictly speaking gets wrong, IMHO (for f=f).

RFC 3676 does not say anything that would prevent you from
recognizing '> > foo' in fixed content as a second level quote
and treating it as such in display.
And indeed mutt already gets this right, as do Apple Mail and
Thunderbird.

Oh, this is by actually accident. For f=f, it gets it right for coloring according to $quote_regexp but not to my strict interpretation of RfC3676-style quoting... But since this is display only I can personally well live with it.

I think we disagree in our understanding of RFC 3676 in this point,
but if you read RFC 3676 again with the question "_why_ do they
define quote depth" in mind, then you'll see.

I already did that and I do agree that quote depths make most sense with flowing. However, you have to admit that the quote level definition is totally independent from flowed and fixed lines. To me this means that there's only one technically valid quoting style.

That other quoting styles possibly don't hurt mutt/other MUAs or match the interpretation of other MUAs is a different story. RfC 3676 defines just this one quoting style and I'd like to see mutt doing the same unless really everybody else does it differently for some time so that it's become defacto standard.

There's also a catch: If you're creating a format=flowed mail
as a reply to a format=fixed mail, then you cannot make any
assumptions about the text you are quoting. RFC 3676 doesn't spell
this out, but IMHO you must then delete all trailing spaces
from the quoted text to ensure that it will not be accidentally
be treated as flowed.

I checked and this is indeed what Apple Mail does.

But you don't want mutt to do that, too?

Yes, I do. I think Apple Mail gets this one right and mutt wrong.
(Thunderbird 2.0 also gets it wrong.)

Text from a format=fixed message is fixed and must be
quoted as fixed text in a format=flowed reply.

This is my understanding of RFC 3676.

I guess we could endlessly debate what "user-inserted hard line breaks" are where agents should trim spaces, whether the authors really had MUAs with external editors in mind (that usually don't know anything about f=f and mail) and whether things one quotes count as such hard line breaks, too.

I think what this means is not related to quoting but to text the user enters. When he hits return, all trailing spaces of that very line are to be removed since return means entering a fixed line. But I could be wrong, though.

My main concern is still that in a discussion you'll loose all f=f benefits if there's only one person doing a format=fixed reply that turns all flowed into fixed lines. For example, in this discussion between us you would have made messages harder to read for me if you did trim spaces though nothing changes for you at all. Why would you want do that?

I'd rather leave it up to the user to ensure he sends out only valid f=f.

For example, my first mail in this thread contained a patch,
and patches always have some lines ending with a space.
If you had quoted this patch in your format=flowed reply with
current mutt, the patch would have been mangled on my display.

...and it would have been my fault, not yours or your agent's.

1) When replying to f=f messages, you want to be abled to use $indent_string if $text_flowed is unset.

Yes.

This is where I think space removal could be relevant for, but as said it's unclear to me if you really want that and if so when exactly.

When creating format=fixed messages there are no spaces to be removed.

In this thread we have:

  you) fixed
  me)  flowed
  you) fixed
  me)  flowed
  ...

So that means when I reply to one of your mails my mutt should trim spaces my mutt earlier send out because the former f=f parts were declared fixed by your mutt... and fixed parts should not have spaces. So, when my mutt makes that assumption why doesn't yours in the first place?

I still think your mutt leaves them in because they don't do harm to it. And I decide that they don't do harm either and leave them in when making my f=f reply. If I find offending lines that could do harm it's IMHO my job to remove them providing interoperability between flowed and fixed messages.

BTW, I meanwhile realized that my patch was much too simple minded
and my claim that it "does the right thing" was wrong. I think the
required changes to mutt are somewhat larger.

Yes. I didn't really think about what exactly needs to be changed, but it's quite a lot... and all probably outside the f=f handler.

For the other problems, I think we're slowly reaching the roots of our disagreement, i.e. we need a referee and/or other opinions... :)

Rocco