From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id E88E21F87F;
	Tue, 20 Nov 2018 07:45:53 +0000 (UTC)
Date: Tue, 20 Nov 2018 07:45:53 +0000
From: Eric Wong <e@80x24.org>
To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason <avarab@gmail.com>
Cc: meta@public-inbox.org
Subject: Re: BUG?: The UI shows an "In-Reply-To" value different than the
 actual value
Message-ID: <20181120074553.72ayiqorwdsvdfoi@dcvr>
References: <87tvkczqk8.fsf@evledraar.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87tvkczqk8.fsf@evledraar.gmail.com>
List-Id: <meta.public-inbox.org>

Æ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.