Re: [Mutt] #2995: Mutt is folding subject line folds using a tab,
[ Sorry for the looong delay, I just overlooked this one. ]
Hi,
* Derek Martin wrote:
> 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.
Yepp, this is what it's like now, i.e. broken.
I was more justifying why, in my re-implementation, decided to keep
using one function for display and send purposes. With my patch, folding
works correctly. Again, folding is done not for all headers but only for
those who need it, others including their way of folding are kept as-is.
> 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.
Oh, that's a really good point. At each edit (from the compose menu),
Mutt know unfolds the header and refolds it using the new logic. I bet
it throws \t away as part of unfolding :-(. I think it has to unfold the
header as otherwise the user would have to do folding by hand. E.g. the
user may change
Subject: quite long
folded long line
another line
to:
Subject: quite long and even longer
folded long line
another line that gets way too long
Not stripping the \t when unfolding is technically correct and is what
RfC2822 says, but it'll break messages sent by mutt in the past made
with wrong folding (upon reply, the header is already folded and so not
touched by the folding implementation)... :(
> I'm of the opinion that this change should simply be reverted, and the
> pre-mutt-1.5.14 behavior restored.
I disagree now that I rewrote it and it passes my simple tests. :-) Did
you have a chance to try the patch?
Rocco