Re: [PATCH] fix indent_string handling with format=flowed
Hi,
On Sat, Oct 13, 2007, Rocco Rutte wrote:
> * Johannes Stezenbach [07-10-12 23:14:21 +0200] wrote:
>> On Thu, Oct 11, 2007, Rocco Rutte wrote:
>
>>> Mutt currently tries to keep interoperability by assuming that non-f=f
>>> aware clients (including mutt itself with $text_flowed unset) treat f=f
>>> mails just like any other mail and leave the spaces alone. As a result,
>>> non-f=f users won't notice the difference at all while f=f users still
>>> benefit from all f=f mails in a thread.
>
>> Mutt currently does more than that: Even with $text_flowed=no it
>> creates replies which are fit for $text_flowed=yes (forced
>> $indent_string=">"). In itself this isn't _wrong_, but is different
>> from what a non-f=f aware MUA would do, and from my perspective
>> it is undesired behaviour.
>
> Contrary to the above, strictly speaking mutt isn't a non-f=f aware client.
> With $text_flowed unset it well recognizes f=f, it just doesn't attempt to
> declare it.
>
> Furthermore, trailing spaces are only important since f=f came up, so I
> guess that most MUAs simply don't care about them if they don't know about
> f=f. Though I can imagine some simply remove trailing spaces for no
> particular technical reason...
>
>> I still think that my patch does the right thing.
>
> I think I see a problem with it. It removes the space between quotes and
> text in the second hunk. I guess you're doing this because with
> $indent_string defaulting to '> ' you'll end up with 2 spaces. However,
> with $text_flowed set, s->prefix is only '>' so you'll remove that space
> for f=f users, too making lines render as '>>>foo' instead of '>>> foo'
> (which some earlier commit to rfc3676.c fixed).
I must confess I'm a bit confused at the moment as to what the
desired behaviour is. So let's talk about this first.
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.
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.
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).
Do you agree?
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.
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.
Johannes