<<< Date Index >>>     <<< Thread Index >>>

Re: [Mutt] #2995: Mutt is folding subject line folds using a tab,



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