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

Message #49 received at 75305 <at> debbugs.gnu.org (full text, mbox):

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

Andrew Cohen <acohen <at> ust.hk> writes:

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

In think this would be potentially to slow. That's what's happening in
nnselect refer article which can cause that it searches on the whole
server e.g. an imap server which means it could take hours to finish
searching.


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

From my point of view when talking about a non-virtual group it does
makes sense to refer to the "current" as in the group that the user is
in when pressing A T.
However I get the point of that not being idea for nnselect groups. To
be honest I did not think of that when writing the patch. I agree using
artgroup is better in this context. This also aligns with the original
behavior I wanted to align with when writing the patch i.e. to include
the groups listed in gnus-refer-thread-use-search but also include the
articles which would be found if gnus-refer-thread-use-search was nil.


From my personal point of the just that was the goal so I could e.g. put
the send group into the list of groups searched when building the thread
including the current group.



Grüße,

Björn

Previous Next

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