Re: [PATCH] fix indent_string handling with format=flowed
Hi,
I've taken some time to read RFC 3676 and conduct some experiments.
Sorry for the long mail, the topic is tricky...
On Thu, Oct 11, 2007, Rocco Rutte wrote:
> * Johannes Stezenbach [07-10-10 20:49:38 +0200] wrote:
>
>> I think when the code which my patch changes is executed, the f=f
>> message has already been converted to a non-f=f message, so it doesn't
>> make sense to suppress $indent_string handling at this stage.
>
> Not really. First, touching rfc3676.c means you do touch the part that
> handles f=f.
Yes, that's where the problem is.
> Second, mutt doesn't convert f=f to non-f=f. It only renders
> the message for your current terminal, making sure it's still a valid f=f
> message. To test this for yourself, edit your message (the parent of this
> reply) and add '; format=flowed' to the Content-Type: the part I wrote will
> be properly rendered as f=f because your mutt didn't convert it to non-f=f.
I noticed that if I have $text_flowed=no and reply to a f=f mail, mutt calls
the editor with a reformatted message. I didn't notice that there are still
trailing spaces. My impression that mutt converts to non-f=f was thus wrong.
(I have $wrap=0 so it seems it isn't formatted for my terminal
but wrapped at FLOWED_MAX=77.)
> 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.
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.
BTW, manual.txt description for $text_flowed says: "Note that
$indent_string is ignored when this option is set."
Which suggests it shouldn't be ignored when $text_flowed is unset.
> I think it's a good idea to keep it that way. But making mutt really
> "convert" f=f to non-f=f by removing the spaces wouldn't be too difficult
> either.
I don't think this would be right, as a non-f=f aware MUA wouldn't do
it, either.
> About the regression on your side: In addition to setting $indent_string
> and $attribution, you could more or less easily have a custom $editor
> script that strips leading '>' quotes mutt added.
That would be a workaround if I can't convince you. ;-/
I still think that my patch does the right thing.
BTW, in addition to "respect $indent_string with $text_flowed=no",
I think it would be useful to have a config option to disable
RFC 3676 handling of received messages altogether and make mutt
behave like a plain old non-f=f aware MUA. That would be especially
useful in those cases where people send patches inlined in
f=f messages, where the patch is actually OK but displayed wrapped.
Just as I write this I notice another thing which might be a bug:
According to RFC 3676 "4.1. Interpreting Format=Flowed":
A series of one or more flowed lines followed by one fixed line is
considered a paragraph, and MAY be flowed (wrapped and unwrapped)
as appropriate on display and in the construction of new messages
(see Section 4.5).
I think this means that a series of fixed lines should not be wrapped.
Thanks,
Johannes