GNU bug report logs - #74905
[PATCH] Implement search for nnvirtual Gnus groups

Previous Next

Full log

View this message in rfc822 format

From: James Thomas <jimjoe <at> gmx.net>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74905 <at> debbugs.gnu.org
Subject: bug#74905: [PATCH] Implement search for nnvirtual Gnus groups
Date: Fri, 20 Dec 2024 12:45:47 +0530

Björn Bidar wrote:

> James Thomas <jimjoe <at> gmx.net> writes:
>
>> James Thomas wrote:
>>
>>> Björn Bidar wrote:
>>>
>>>> James Thomas <jimjoe <at> gmx.net> writes:
>>>>
>>>>> Björn Bidar wrote:
>>>>>
>>>>>> This patch implements search for nnvirtual. I'm using
>>>>>> publi-inbox's
>>>>>> with nnvirtual to group each group into one.
>>>>>> However searching wasn't possible in these nnvirtual groups.
>>>>>> I implemented gnus-search-run-search based on the existing
>>>>>> nnselect gnus-search-run-search function.
>>>>>
>>>>> Thanks! I haven't looked into it, but here are some quick comments:
>>>>>
>>>>>> I'm looking for feedback on the patch. I don't exactly know how
>>>>>> the search function is called when multiple groups of the same
>>>>>> type
>>>>>> are
>>>>>> involved. For nnvirtual each group is its on server, does that
>>>>>> mean
>>>>>> the
>>>>>> function will be always called only for each group? In that case
>>>>>> everything should be good.
>>>>>
>>>>> That seems to be the case: see
>>>>> gnus-group-read-ephemeral-search-group
>>>>> and gnus-group-make-search-group.
>>>>
>>>> OK good than my understanding from my tests matched with the rest of
>>>> the
>>>> code.
>>>> Thanks for these examples I haven't looked at the create group
>>>> functions
>>>> as the searched methods don't have to create groups even when they
>>>> start
>>>> a new search by another backend just like e.g. if the user would
>>>> call
>>>> a
>>>> search on another imap group.
>>>>
>>>>>> +(deffoo nnvirtual-request-list (&optional server)
>>>>>> +  (when (nnvirtual-possibly-change-server server)
>>>>>> +    (with-current-buffer nntp-server-buffer
>>>>>> +      (erase-buffer)
>>>>>> +      (dolist (group nnvirtual-component-groups)
>>>>>> +        (insert (format "%S 0  1 y\n" group))))
>>>>>> +    t))
>>>>>
>>>>> Did you check if gnus-start.el#L1801 withstands this? It seems to
>>>>> me
>>>>> to
>>>>> assume that nnvirtual doesn't have -request-list.
>>>>
>>>> It does. If the user has falsely add nnvirtual to one of the select
>>>> methods than it will call it try to call the function which doesn't
>>>> fail
>>>> or do anything. The only thing that happens from that is it will
>>>> show
>>>> the false results as groups contained in the nnvirtual method
>>>> without
>>>> a
>>>> parameter.
>>>
>>> No, I mean, the point of that code seems to be that nnvirtual is
>>> activated _last_, i.e. after any component groups of other backends.
>>
>> No, sorry, I was a little confused about this. But it seems to me that
>> -request-group removes each group from the component list (unlike your
>> -request-list). Is that relevant? IDK. The latter seems to do info
>> updation as well, based on -always-rescan.
>>
>
> Request list supposed to list the available groups on the server it is
> also for example used in gnus-search-imap class gnus-search-run-search
> function. Since for the case of nnvirtual all groups on the server
> are all groups contained in the group it is the right function.

True, but since it returns the group data like -request-group and often
acts as a _substitute_, shouldn't it mimic its operation? If not, is
there a good reason?

> I took all the explenation for each functions purpose from the manual
> section linked below:
> (info "(gnus) Required Back End Functions")

Please do look at how they're called, as well; for a fuller picture.

> To me the code just reads like that that for nnvirtual
> the groups are activated this way only because
> it doesn't have request list.
>
>>
>> No, I mean, the point of that code seems to be that nnvirtual is
>> activated _last_, i.e. after any component groups of other backends. And
>> it's not just select methods: even Foreign Groups are included, no?
>>
>>> Should verify that nnvirtual has arguments? So far it is possible
>>> to add nnvirtual to select methods with "" but this is invalid.
>>
>> I'm not sure what you mean, but it does have arguments: the components
>> regexp, for one.
>>
>
> It does have arguments exactly but you can add nnvirtual without
> arguments or technically an empty argument to select methods.
>
>>> If nnvirtual isn't added to select methods nothing happens besides
>>> the regular activation.
>>
>> Couldn't someone have added one? Say, with the above argument?
>
> I guess so but that isn't the intended way of using nnvirtual,
> also it wouldn't take care of the request of the setup such
> as creating the associated group.

Well now you've made me look at it... :-)

Try this:

- In *Groups*: j nnvirtual:Test RET
- S l 3 RET
- e "nnvirtual:Test" C-c C-c
- q
- Add to -secondary-select-methods:

  (nnvirtual "Test"
		   (nnvirtual-component-regexp
                   ;; Put in some group you have.
		   "^$\\|\\(^nnml\\+archive:sent$\\)"))
                   
M-x gnus

> Regular activation meant in this context that the request-list function
> is called but without a argument the nnvirtual-server doesn't contain
> any groups.

OK. But I don't think I've come across that term.

Also, your -request-list makes the component groups subscribable from
the Server buffer. That seems wrong too: the backend ought to have only
one (umbrella) group, no?

--

Previous Next

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