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
