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

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