*Re: BUG?: The UI shows an "In-Reply-To" value different than the actual value
2018-11-19 21:48 BUG?: The UI shows an "In-Reply-To" value different than the actual value Ævar Arnfjörð Bjarmason
@ 2018-11-20 7:45 ` Eric Wong
2018-11-20 12:43 ` Leah Neukirchen0 siblings, 1 reply; 3+ messages in thread
From: Eric Wong @ 2018-11-20 7:45 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: meta
Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> (I'm not on-list, please keep me CC'd)
Yep, it's expected and strongly encouraged behavior here to
reply-all :) Centralization is the enemy, and I don't expect
many people are subscribed to this list.
> Maybe I'm being evil, but when I talk about another E-Mail I add it to
> the "References" header. Reading
> https://tools.ietf.org/html/rfc5322#section-3.6.4 this may be more evil
> than I thought at first.
This part of RFC 5322?
Note: Some implementations parse the "References:" field to
display the "thread of the discussion". These implementations
assume that each new message is a reply to a single parent and
hence that they can walk backwards through the "References:" field
to find the parent of each message listed there. Therefore,
trying to form a "References:" field for a reply that has multiple
parents is discouraged; how to do so is not defined in this
document.
Yes, public-inbox does treat the order of References as significant.
> Anyway, if you look at
> https://public-inbox.org/git/87va4szr2q.fsf@evledraar.gmail.com/ you can
> see one such E-Mail. The UI shows:
>
> In-Reply-To: <874lcd1bub.fsf@evledraar.gmail.com>
>
> But as the "raw" view shows these are the actual headers:
>
> References: <9e293b1b-1845-1772-409b-031c0bf4d17b@gmail.com>
> <871s7g29zy.fsf@evledraar.gmail.com>
> <6f0ff2e3-4019-1dcc-f61a-cd0919b9a247@gmail.com>
> <874lcd1bub.fsf@evledraar.gmail.com>
> In-reply-to: <6f0ff2e3-4019-1dcc-f61a-cd0919b9a247@gmail.com>
>
> I'd expect the web UI to show the value of the header in its primary
> view.
Yes, I understand how that can be disconcerting...
Perhaps the View.pm code can actually use the In-Reply-To header
if it exists, but that may throw off the thread skeleton code
and Xapian index.
When I was working on this, I found References: more consistent
and easier-to-parse than In-Reply-To; as the latter could
contain random human-readable phrases. Thus the code favors
using the References header for threading.
lib/PublicInbox/MID.pm has this, currently:
# last References should be IRT, but some mail clients do things
# out of order, so trust IRT over References iff IRT exists
sub references ($) {
my ($hdr) = @_;
my @mids;
foreach my $f (qw(References In-Reply-To)) {
my @v = $hdr->header_raw($f);
foreach my $v (@v) {
push(@mids, ($v =~ /<([^>]+)>/sg));
}
}
uniq_mids(\@mids);
}
So, it appears the comment and code don't match (it's been a
while :x). Maybe this is needed, too?
diff --git a/lib/PublicInbox/MID.pm b/lib/PublicInbox/MID.pm
index cd56f27..a775fdc 100644
--- a/lib/PublicInbox/MID.pm
+++ b/lib/PublicInbox/MID.pm
@@ -79,7 +79,9 @@ ($)
push(@mids, ($v =~ /<([^>]+)>/sg));
}
}
+ @mids = reverse(@mids);
uniq_mids(\@mids);
+ [ reverse(@mids) ];
}
sub uniq_mids ($) {
Note: untested.
^permalinkrawreply [flat|nested] 3+ messages in thread

*Re: BUG?: The UI shows an "In-Reply-To" value different than the actual value
2018-11-20 7:45 ` Eric Wong@ 2018-11-20 12:43 ` Leah Neukirchen0 siblings, 0 replies; 3+ messages in thread
From: Leah Neukirchen @ 2018-11-20 12:43 UTC (permalink / raw)
To: Eric Wong; +Cc: Ævar Arnfjörð Bjarmason, meta
Eric Wong <e@80x24.org> writes:
> When I was working on this, I found References: more consistent
> and easier-to-parse than In-Reply-To; as the latter could
> contain random human-readable phrases. Thus the code favors
> using the References header for threading.
>
> lib/PublicInbox/MID.pm has this, currently:
>
> # last References should be IRT, but some mail clients do things
> # out of order, so trust IRT over References iff IRT exists
This is also what jwz recommends (https://www.jwz.org/doc/threading.html):>> I've been informed that recent versions of Eudora violate this
>> standard: they put the parent Message-ID in the In-Reply-To header,
>> but do not duplicate it in the References header: instead, the
>> References header contains the grandparent, great-grand-parent,
>> etc.
>> This implies that to properly reconstruct the thread of a message
>> in the face of this nonstandard behavior, we need to append any
>> In-Reply-To message IDs to References.
(mthread(1) of mblaze does the same.)
--
Leah Neukirchen <leah@vuxu.org> http://leah.zone
^permalinkrawreply [flat|nested] 3+ messages in thread