- # Sadly, we sort here anyways since the fill-in-the-blanks References:
- # can be shakier if somebody used In-Reply-To with multiple, disparate
- # messages. So, take the client Date: into account since we can't
- # always determine ordering when somebody uses multiple In-Reply-To.
- # We'll trust the client Date: header here instead of the Received:
- # time since this is for display (and not retrieval)
- _set_parent(\%id_table, $_) for sort { $a->{ds} <=> $b->{ds} } @$msgs;
- my $ibx = $ctx->{ibx};
- my $rootset = [ grep {
- !delete($_->{parent}) && $_->visible($ibx)
- } values %id_table ];
- $rootset = $ordersub->($rootset);
- $_->order_children($ordersub, $ctx) for @$rootset;
- $rootset;
-}
-
-sub _set_parent ($$) {
- my ($id_table, $this) = @_;
-
- # B. For each element in the message's References field:
- defined(my $refs = $this->{references}) or return;
-
- # This loop exists to help fill in gaps left from missing
- # messages. It is not needed in a perfect world where
- # everything is perfectly referenced, only the last ref
- # matters.
- my $prev;
- foreach my $ref ($refs =~ m/$MID_EXTRACT/go) {
- # Find a Container object for the given Message-ID
- my $cont = $id_table->{$ref} //=
- PublicInbox::SearchThread::Msg::ghost($ref);
-
- # Link the References field's Containers together in
- # the order implied by the References header
- #
- # * If they are already linked don't change the
- # existing links
- # * Do not add a link if adding that link would
- # introduce a loop...
- if ($prev &&
- !$cont->{parent} && # already linked
- !$cont->has_descendent($prev) # would loop
- ) {
- $prev->add_child($cont);