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 #52 received at 75305 <at> debbugs.gnu.org (full text, mbox):
Ping! Can we please make some progress here?
> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, eric <at> ericabrahamsen.net,
> cohen <at> andy.bu.edu, 75305 <at> debbugs.gnu.org
> 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
>
This bug report was last modified 97 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.