* [PATCH 0/2] www: re-sort messages for strict|loose matches
@ 2024-01-01 1:07 Eric Wong
2024-01-01 1:07 ` [PATCH 1/2] over: re-sort Subject matches for WWW /T/ endpoint Eric Wong
2024-01-01 1:07 ` [PATCH 2/2] view: always show strict|loose note w/ multi-roots Eric Wong
0 siblings, 2 replies; 3+ messages in thread
From: Eric Wong @ 2024-01-01 1:07 UTC (permalink / raw)
To: meta; +Cc: Askar Safin
1/2 fixes the bug reported by Askar Safin, while 2/2 makes
the multi-rootedness of threads which triggered the bug more
obvious.
Both patches deployed to my lore mirror at yhbt.net/lore:
https://yhbt.net/lore/lkml/20231120011248.396012-1-stefanb@linux.ibm.com/T/
Eric Wong (2):
over: re-sort Subject matches for WWW /T/ endpoint
view: always show strict|loose note w/ multi-roots
lib/PublicInbox/Over.pm | 5 +++++
lib/PublicInbox/View.pm | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH 1/2] over: re-sort Subject matches for WWW /T/ endpoint
2024-01-01 1:07 [PATCH 0/2] www: re-sort messages for strict|loose matches Eric Wong
@ 2024-01-01 1:07 ` Eric Wong
2024-01-01 1:07 ` [PATCH 2/2] view: always show strict|loose note w/ multi-roots Eric Wong
1 sibling, 0 replies; 3+ messages in thread
From: Eric Wong @ 2024-01-01 1:07 UTC (permalink / raw)
To: meta; +Cc: Askar Safin
When retrieving loose (Subject) matches for a thread, we wanted
the most recent matches in reverse chronological order.
However, when displaying the /T/ endpoint generating the thread
skeleton, we prefer ascending chronological order to match the
flow of the conversation.
Reported-by: Askar Safin <safinaskar@gmail.com>
Link: https://public-inbox.org/meta/CAPnZJGAqsh8ZhPaCAy5M2NZVNcWrr_Hr94t32VXiyiTXwD9jRQ@mail.gmail.com/
---
lib/PublicInbox/Over.pm | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/lib/PublicInbox/Over.pm b/lib/PublicInbox/Over.pm
index 4eed4f46..3b7d49f5 100644
--- a/lib/PublicInbox/Over.pm
+++ b/lib/PublicInbox/Over.pm
@@ -200,6 +200,11 @@ ORDER BY $sort_col DESC
# TODO separate strict and loose matches here once --reindex
# is fixed to preserve `tid' properly
push @$msgs, @$loose;
+
+ # we wanted to retrieve the latest loose messages; but preserve
+ # chronological ordering for threading /$INBOX/$MSGID/[tT]/
+ $sort_col eq 'ds' and
+ @$msgs = sort { $a->{ds} <=> $b->{ds} } @$msgs;
}
($nr, $msgs);
}
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH 2/2] view: always show strict|loose note w/ multi-roots
2024-01-01 1:07 [PATCH 0/2] www: re-sort messages for strict|loose matches Eric Wong
2024-01-01 1:07 ` [PATCH 1/2] over: re-sort Subject matches for WWW /T/ endpoint Eric Wong
@ 2024-01-01 1:07 ` Eric Wong
1 sibling, 0 replies; 3+ messages in thread
From: Eric Wong @ 2024-01-01 1:07 UTC (permalink / raw)
To: meta
For thread skeletons with multiple roots, it makes sense to
note the strict|loose delineation even when the first message
matches the desired Message-ID.
---
lib/PublicInbox/View.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/PublicInbox/View.pm b/lib/PublicInbox/View.pm
index d81c66b7..02b93d7b 100644
--- a/lib/PublicInbox/View.pm
+++ b/lib/PublicInbox/View.pm
@@ -885,8 +885,8 @@ sub thread_results {
my $tip = splice(@$rootset, $idx, 1);
@$rootset = reverse @$rootset;
unshift @$rootset, $tip;
- $ctx->{sl_note} = strict_loose_note($nr);
}
+ $ctx->{sl_note} = strict_loose_note($nr);
}
$rootset
}
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-01-01 1:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-01 1:07 [PATCH 0/2] www: re-sort messages for strict|loose matches Eric Wong
2024-01-01 1:07 ` [PATCH 1/2] over: re-sort Subject matches for WWW /T/ endpoint Eric Wong
2024-01-01 1:07 ` [PATCH 2/2] view: always show strict|loose note w/ multi-roots Eric Wong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).