Re: [PATCH] fix indent_string handling with format=flowed
Hi again,
On Mon, Oct 15, 2007, Rocco Rutte wrote:
> * Johannes Stezenbach [07-10-14 21:54:36 +0200] wrote:
>> At the moment, with $text_flowed set, replies to non-flowed mails
>> get ugly quoting with '>' instead of '> '. Mutt _displays_ such
>> quoting as '> ', but to people with other MUAs it might look bad.
>
> Not really. If mutt did send that line out quoted as '> ', to other clients
> it means that the line has been space-stuffed and that space is to be
> removed to just '>' (read: it'll always look as '>' to other clients except
> they add a space).
According to RFC 3676:
Note that because of space-stuffing, the lines
>> Exit, Stage Left
and
>>Exit, Stage Left
are semantically identical; both have a quote-depth of two, and a
content of "Exit, Stage Left".
Since the goal of RFC 3676 is to create messages which are as
compatible as possible with plain old MUAs, mutt should IMHO create
the ">> Exit" variant (i.e. the first level of quoting adds
'> ' and any further level just '>').
I looked through my mail boxes and it seems that this is
what Apple Mail is doing.
For example, compare the quoting of your mutt and mine
in the marc list archives:
http://marc.info/?l=mutt-dev&m=119203573713083&w=2
http://marc.info/?l=mutt-dev&m=119204221524209&w=2
> However, after removing such spaces, concatenating lines and rewrapping
> them, mutt adds a space again for display purposes only so that it looks
> nicer. I didn't check the archives, but IIRC there was some discussion
> about it some time ago.
Yes, IMHO this is correct behaviour. RFC 3676 processing removes the
space and then you add it back for display.
>> I think to correct this behaviour, the forcing of prefix='>' at the
>> start of _mutt_copy_message() must be removed. But I guess this
>> was done there and not in rfc3676.c because mutt tries to handle
>> quote levels in RFC 3676 way *even when replying to non-RFC 3676 mails*.
>> IMHO mutt just shouldn't do this, then to problem would go away.
>
> I'm not really sure what you mean here. All that code does is set the
> prefix for properly quoting lines. For $text_flowed=yes it always has to be
> '>' (without space) since RfC 3676 requires that. Otherwise it's what the
> user configured, though it's ignored when replying to a f=f mail regardless
> whether $text_flowed is set or not (for interoperability with f=f).
In the context of what I wrote above this is not correct.
With $text_flowed=yes there are two cases:
1. reply to a format=flowed mail: to be handled by rfc3676.c,
count quoting levels and add '>>> ' according to level
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)
>> Or it should do it correctly, i.e. use '> ' for the first level
>> of quoting and '>' for further levels (which is a bit more work
>> to implement that just forcing a fixed prefix).
This seems to be what Apple Mail is doing. Apple Mail does this
even when replying to format=fixed mails. Apple Mail also seems
to count quoting levels fuzzily, i.e. it converts '> > foo'
into '>>> foo' on reply. (Which IMHO is unnecessary but doesn't hurt.)
(A quick look at some mailing list inbox of mine shows Thunderbird does
this, too.)
> For the f=f handler or in what situation exactly? For both, 1) sending out
> f=f messages with $text_flowed set and 2) replying to f=f messages this
> breaks message handling on the receiver's side.
>
> For 1), a line of a f=f message '> >>foo' has a quote level of 1 and the
> line is '>>foo', not 3 and 'foo'. For 2), it again breaks interoperability.
IMHO it doesn't break anything. I think the RFC 3676 quoting levels
are only meaningful wrt to reflowing quoted lines. But if a mail is
format=fixed you can't reflow it anyway (see below). The MUA is
still allowed to recognize '> >>foo' as three levels of quoting and
display it accordingly (just like $quote_regexp in mutt does).
>> My initial problem is the contrary case, $text_flowed unset and
>> replies to flowed mails. My opinion here is that mutt should
>> honour $indent_string in this case. I think the reason it doesn't
>> is "improved interoperability with format=flowed users" when
>> they reply to the reply.
>
> I do see your problem, but the subject is quite tricky. Again: if mutt did
> use $indent_string, it would have to strip all trailing spaces in addition
No.
> to make sure that a f=f reply on that message still looks okay (but since a
> replying user will generate f=f it'll still require him to take some
> actions; e.g. when he gets quoting as '> >>foo', he'll have to fix it to
> '>>>foo' first while making up a reply).
The other guy gets a format=fixed mail and if he wants to
create a format=flowed reply it is *his* responsibility to
fix things up -- see below.
> So I think we're again talking about a "downgrade format=flowed to
> format=fixed" option, right?
>
> Because in order to be abled to use $indent_string on f=f messages, mutt
> (for interoperability) has to make sure no parts can be flowed later on by
> f=f replies. As I wrote in the other mail, in that case no using the f=f
> handler won't do it since the default text/plain handler leaves spaces in.
Again, this is the responsibility of the one creating the format=flowed reply.
>> However, as I explained before:
>
>>> 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 that's the opposite case of your initial problem, no?
Yes, but once this is implemented correctly you'll see that
my initial problem is automatically also solved. ;-)
> Well, I think we agree that in the end the fixed part must render properly
> as part of the f=f message. I think it's up to the user to ensure it while
> you think it's to mutt, correct?
I think mutt is buggy. ;-)
At the bottom of this is:
- if you see a quoted line with a trailing space in a format=fixed
mail, you seem to assume it must obviously come from a
format=flowed mail thus you can treat it as such when creating
a reply
- but I on the contrary think that this assumption is invalid and
you must treat the line as fixed by removing the space when
creating a reply
Im terribly sorry if all that sounds like I'm splitting hairs.
Also, I don't have any idea what other MUAs do, two of my
office mates are Apple users so that's mostly what I have for
comparison.
Thanks,
Johannes