Re: [Mutt] #2995: Mutt is folding subject line folds using a tab,
#2995: Mutt is folding subject line folds using a tab, which appears to be
against
RFC 2822
----------------------+-----------------------------------------------------
Reporter: frnkblk | Owner: mutt-dev
Type: defect | Status: new
Priority: minor | Milestone: 1.6
Component: mutt | Version: 1.5.17
Resolution: | Keywords: header folding white-space
----------------------+-----------------------------------------------------
Comment(by Derek Martin):
{{{
On Sat, Apr 25, 2009 at 11:20:10AM +0200, Rocco Rutte wrote:
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.
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2995#comment:>
Mutt <http://www.mutt.org/>
The Mutt mail user agent