Re: [PATCH] fix indent_string handling with format=flowed
Hi,
On Thu, Oct 18, 2007, Rocco Rutte wrote:
>
> 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
For 1, 2, and 4 I fully agree. For 3 I think it isn't required
(because plain old MUAs also wouldn't do it), but it could
potentially improve interoperability because it avoids problems
caused later by other MUAs which don't implement 2.
> 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.
I think there are only two ways to address the quoting problem:
1. remove trailing spaces
2. canonicalize quote prefixes created by other MUAs
Historically plain old MUAs were free to choose any quote prefix
so 2 is not really feasible (but of course you could argue
it's their fault if it breaks because of a non-standard quote prefix).
E.g. some users like to use the initials in the quote prefix, so
after flowed -> other MUA -> flowed you already
have ">JS> foo... " lines which are displayed mangled. I don't
know of a fool proof way to determine that ">JS " is a quote
prefix and not part of the text.
Option 1 cannot fail but has the downside of killing flowability
of the quoted text. But since the mail would also contain some
new fixed text along with the quoted text this is IMHO not
a big drawback. (I.e. users with small-screen mobile devices
are fucked anyway.)
> 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...
Well, diff output will have trailing spaces for common empty
lines in the two diff inputs (e.g. look at mutt changeset 35e5c34b7e91).
For review as practiced on serveral development mailing lists
it is important that the patch in the original mail is sent
unaltered (so it can be applied with "patch" or "hg import"),
but it must also stay _readable_ in replies (usually only
small snippets are quoted for discussion).
So if the patch is sent inlined in a text=fixed mail and your
reply is text=flowed you better make sure the trailing spaces
are removed.
> 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.
I've looked at a lot of mails generated by other MUAs in the
last days and there are indeed many that have problems. :-(
In some cases users might want to manually repair the quoting
so they can send proper text=flowed replies. Maybe mutt could
offer the option not to strip the spaces in this case. But I
guess most users would not care to do it.
> So, either way has advantages and disadvantages and we "just" need to
> decide which one to implement.
Please take your time to think it through and to discuss this
with others. There's no need to rush.
Thanks,
Johannes