Re: [PATCH] fix indent_string handling with format=flowed
Hi,
* Johannes Stezenbach [07-10-18 00:11:31 +0200] wrote:
On Tue, Oct 16, 2007, Rocco Rutte wrote:
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?
Yeah, I see what your goal is. And I agree it is a good one.
However, I think interoperability with plain old MUAs is
more important, as it is what RFC 3676 is all about.
Ah, yes. That makes sense to me, too.
Basically mutt interoperates fine with other mutts, with any mix
of $text_flowed=yes and $text_flowed=no. But there's a problem
interacting with plain old MUAs (in the following example I
used mailx with indentprefix="> ").
I created a text=flowed message in mutt, replied in mailx,
replied in mutt, replied in mailx, replied in mutt.
The result is:
[...]
If you agree that there is a problem, then please fix ;-)
Well, technically how mutt interprets the message is fully correct since
'>> >> foo' parses into quote depth 2 and content '>> Foo'.
But I see your point and agree there's a problem and "format=flawed" is
true once more. If trimming spaces is the preferred solution, I need
more time to come up with the logic of when to do it and when not. First
thought:
original: flowed? | reply: flowed? | trim spaces
1 N N N
2 N Y Y
3 Y N Y
4 Y Y N
1: fixed reply to fixed mail: no problem
2: flowed reply to fixed mail: your example, problem
3: fixed reply to flowed mail: potential problem later on, esp. with
other MUAs
4: flowed reply to flowed mail: no problem
The only thing I'm not sure about and why I hesitate to be all for
trimming spaces is that I can't really judge whether there are
situations such a behavior would break other things.
For example, someone sends a patch inlined in a mail to some project and
the project is pedantic about not to allow for trailing spaces in code,
a reply won't show the space (according to above table it wouldn't
really matter if the original or reply was fixed). Of course, this is to
be handled by committers and SCMs not MUAs, but still it may introduce
other inconveniences...
A totally different solution to that problem in 2) would be to not trim
spaces at all but allow the user to disable f=f handling completely. A
disadvantage would be that other f=f MUAs might have problems and that
it requires explicit user action to make the message render properly.
So, either way has advantages and disadvantages and we "just" need to
decide which one to implement.
Rocco