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>