On Sat, Apr 25, 2009 at 11:20:10AM +0200, Rocco Rutte wrote: > > I suspect the fundamental problem is that whoever wrote this wanted it > > to be used both for writing the headers when sending the message, and > > also when displaying it... and probably that's the Wrong Thing(tm), > > since those two operations are inherently very different. But I would > > need to dig into this much more than I had time for. > > Well, I don't think it's that wrong. Sure, these are different > operations but breaking long header lines is basically the same > so both share the same code (well, except that for readability on > display we want to fold with tab). That is the crux of the problem, and here's why it's not basically the same as rfc2822 folding: RFC 2822 allows mailers to do folding at transmission time, after the user has completed all edits, which can be reliably unfolded by the receiving mailer. By contrast, mutt is inserting an *additional* character which is not in the original input stream, in a context where it is not normally allowed to make such an insertion, *when the users are about to make their own edits*. Moreover, it is actually *removing* space when it folds with a tab. This is not like RFC 2822 folding, which *only* inserts and removes a "\n" when appropriate, in a deterministic manner. Furthermore, it does this *conditionally* which means it's not possible after the user's editing session to determine whether any occurences of "\n\t" in a header were added by Mutt or by the user. If they were added by Mutt, they should be removed (and replaced by whatever was there before, probably a space but we don't know that for a fact), and if they were added by the user, they should be left as is. It's possible to either tell mutt to remember whether it folded the line, or to simply always fold lines, and then always unfold them, but there's no way to guarantee that you won't unfold a tab that the user actually wanted. This might be OK, since people rarely use tabs in headers in practice, but it's technically wrong. I believe it's possible to separate the case of Mutt formatting messages for display from Mutt passing messages to the user's editor, but I don't think it's worth doing, as it's more complicated, and you still have to figure out the interactions with non-ASCII character sets. I'm of the opinion that this change should simply be reverted, and the pre-mutt-1.5.14 behavior restored. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgp3L2TvtUg4h.pgp
Description: PGP signature