#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>
