>>>>> "BB" == Björn Bidar <bjorn.bidar@thaodan.de> writes:

    BB> Andrew Cohen <acohen@ust.hk> writes:
    >>>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
    >> 
    EZ> Ping! Can we please make some progress here?
    >> 
    >> All set to commit, I think. I have been running with the
    >> following in my personal tree for the past few weeks without
    >> issue. If no objections we can commit.

    BB> I would have hoped there would be a response to my mail. Further
    BB> I don't mind to refactor the contribution to the issues you
    BB> mentioned but I don't think it is great to just take over IMHO.


I sincerely apologize. It was never my intent to take over and I
definitely don't want to make you feel disenfranchised. I am perfectly
happy to let you continue to manage this issue.

Eli contacted me about this since I wrote and maintain the code that is
implicated in this change. In the end I thought that the tiny change
(along with the defcustom and documentation changes that you suggested)
in gnus-sum.el was the best way to introduce the feature that you
suggested.

And again I apologize for not responding to your previous email.

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

This seems like something might be broken? I routinely search imap
servers with 100 groups and it finishes in a few seconds. Does your imap
server maintain a searchable index? All of them should, and then the
searching is basically instantaneous, aside from the cost of the network
round trip and the changing of groups.

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

Although I originally suggested this, I think I was mistaken for doing
so. The nnselect search routine does indeed collect the component groups
and search them. So this aligns the behavior of 'current with
gnus-refer-thread-use-search set to 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.

Agreed. 

FWIW here is the patch with Eli's suggested fixes incorporated. Feel
free to discard---I won't be offended.