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

Re: [Mutt] #3090: Mutt removes In-Reply-To header field



#3090: Mutt removes In-Reply-To header field

Comment (by pdmef):

 Replying to [comment:13 agriffis]:
 > Replying to [comment:12 pdmef]:

 > > Replying to [comment:9 vinc17]:

 > > > I'm not sure I understand. Do you mean that when generating a
 message to be edited (compose), you generate a References header instead
 of the current In-Reply-To, and when the user quits the editor, the
 References contents are used to generate the References and In-Reply-To
 headers?

 > > Exactly. I didn't look into it yet, but if that worked, I'd be my
 preferred solution since it wouldn't mean to touch any parsers.

 > pdmef: If you could provide more explanation or even a (possibly
 incomplete) patch, I'd be interested.  So far, I don't understand how your
 suggested approach does anything other than move the problem around, and
 possibly creates other problems...

 Well, from my point of view the problem is that when mutt generates a
 partial message with edit_headers set and the message-id not containing
 exactly 1 @ (or not being "valid" by mutt's In-Reply-To expectations),
 mutt later can't parse that and breaks threading as it simply drops that
 message-id.

 I don't think the parser for In-Reply-To should be touched to solve the
 problem because it implements a heuristic and changing a heuristic is bad
 when you can't test that change against sample data.

 That said, the only way out I currently see is to find a way to get the
 broken message-id accross the editor. It's a feature that the parent's
 message-ids are available with edit_headers set so that users being sure
 what they're doing can adjust threading (i.e. not writing it out and
 reading it back isn't a solution).

 So, my first thought was to not add a In-Reply-To header with the parent
 message-ids but a References header to the message being edited by the
 user. If we also change mutt_parse_references() to only require exactly
 one @ for In-Reply-To but accept everything else otherwise (kind of what
 you suggested), I think this could work and be a simple patch.

 But I didn't look further into code yet.

 Can you explain why that moves the problem around?

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3090#comment:14>