GNU bug report logs - #75305
31.0.50; gnus-refer-thread-use-search isn't exact enough about how the current group is searched

Previous Next

Full log

View this message in rfc822 format

From: Andrew Cohen <acohen <at> ust.hk>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: eric <at> ericabrahamsen.net, 75305 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, cohen <at> andy.bu.edu
Subject: bug#75305: 31.0.50; gnus-refer-thread-use-search isn't exact enough about how the current group is searched
Date: Mon, 03 Feb 2025 20:20:11 +0800

>>>>> "AC" == Andrew Cohen <acohen <at> ust.hk> writes:

>>>>> "BB" == Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
    AC> [...]

    BB> That look about right. What wasn't correct about the code?

    AC> I shouldn't have said the code wasn't correct---its fine, but it
    AC> just does something slightly different. When coming from an
    AC> nnselect group the default in thread referral is to search the
    AC> group that contains the originating article. (This is the
    AC> "artgroup" in the code that I sent, rather than "group").

OK, I'm having second thoughts about this, and want to know what Björn
thinks.

To clarify, here is the issue:

In an nnselect group, the articles can come from anywhere (different
groups, different servers, different backends). This virtual group could, in
principle, contain articles from hundreds of different real groups.

When gnus-refer-thread-use-search is nil, thread-referral only looks
in the real group that the referring article comes from. This has been
the case since I added this feature a million years ago, and I am
confident this is the right thing.

But if we specify the 'current symbol we have a choice: we can search
the real group that the underlying article comes from, or we can search
all the real groups from which the articles in the nnselect group come
from.

Björn asked for this feature in order to have more control over which
groups are searched. Including a potentially lengthy list of groups to
search just because they are included in the nnselect group seems like
less control (and probably overkill in trying to find the full
thread). Also, searching many groups can be slow, which would certainly
make this painful if there are lots of groups involved. It's also
unpredictable---the articles that show up in the group might come from
different underlying groups at different times, depending on how the
nnselect group is constructed (for example I have a todo group that
includes articles from many different sources: gmail, nntp, outlook and
a few others. At any given moment I may have articles from many
different sources, or only from one or two).  Finally the other elements
of the gnus-refer-thread-use-search list are likely to overlap with some
of these groups, which would then get searched twice (or we would have
to complicate the code to try to remove duplicates, which would also be
painful. We would have to find all groups on each server and filter out
the duplicates, which can be slow).

So my feeling is that the right thing here is to interpret 'current to
again be the real group that holds the originating article being
referred, which is what I did in my code. But we could certainly allow
it to include all the real groups that contain articles in the current
nnselection. So that's my question for Björn. 

Best,
Andy
-- 
Andrew Cohen

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.