From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74905: [PATCH] Implement search for nnvirtual Gnus groups Date: Sun, 22 Dec 2024 17:07:39 +0530 Message-ID: <86pllkj6d8.fsf@gmx.net> References: <86zfktesxb.fsf@gmx.net> <87bjx96ln5.fsf@thaodan.de> <86pllozkq4.fsf@gmx.net> <86ldwcziff.fsf@gmx.net> <87y10c1p21.fsf@thaodan.de> <86v7ve9658.fsf@gmx.net> Reply-To: James Thomas Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1339"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74905@debbugs.gnu.org To: =?UTF-8?Q?Bj=C3=B6rn?= Bidar Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 22 12:40:35 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tPKK2-0000B4-GN for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Dec 2024 12:40:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPKJe-0007TM-SC; Sun, 22 Dec 2024 06:40:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPKJY-0007Oy-Cb for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 06:40:05 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPKJX-00026m-3r for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 06:40:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:Date:In-Reply-To:From:To:Subject; bh=AdNeGBd7OQKLNhANTiXxCs+dGgFo6Yh1n3a3xBiDkaE=; b=lblsILj+YcV6IlyYbK1eNzIuyHol4hrsOQenl3wP63ItwXjI4LkLkmU+alCHAtH5j5TQ8MFZwdYJsS8VE+7F34OI07EdUVLGWyiuA5G+UqlEAUEHtZOvL7ZUowG9NUHSUBw/72DTWqs2zETlXOiEirEk4XiRsV5FiQSEwB0qPqX1FE/mJ0MwGUJQ8eH6wSTxCMEdHB8vRPP0wEU+cgy+JCplgPqZpAnNOoReJF1OccHGPUVs86puqZH1ejwglUDWkwSumt029lZVahqsR+9l3XgH7zdcq+/spZo8kkWUwXTaQxNZoGEk08JmdWx+L1ENuaw7D/D5NJAH6SmqR34adg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tPKJW-0007BE-UW for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 06:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: James Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Dec 2024 11:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74905 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74905-submit@debbugs.gnu.org id=B74905.173486758327550 (code B ref 74905); Sun, 22 Dec 2024 11:40:02 +0000 Original-Received: (at 74905) by debbugs.gnu.org; 22 Dec 2024 11:39:43 +0000 Original-Received: from localhost ([127.0.0.1]:49186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPKJC-0007AH-58 for submit@debbugs.gnu.org; Sun, 22 Dec 2024 06:39:43 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:33881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPKJ3-00079Q-9N for 74905@debbugs.gnu.org; Sun, 22 Dec 2024 06:39:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1734867567; x=1735472367; i=jimjoe@gmx.net; bh=AdNeGBd7OQKLNhANTiXxCs+dGgFo6Yh1n3a3xBiDkaE=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:Date:Message-ID: References:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=Ffi/hQ7hThiIXq25mG2nR0Awhka8CwUFshhsgELK1bFqD+5GXJ+DABIehXPQu+82 jDYWL5seU1Qx0IqSgTcmtKl+GiXm/rm6LygCnacoH7mY/wM0eU7xqM8YNUr9kSxQ5 xb7f8+WzUefW/Vn7VSX/dzC5n9+QQ0oF6uJpTmWQJTTAIyJTQqo/v0WD5lr7A0XmQ heDms4Q//Srt+BTRcLGxf9mP4xVmJTplW4aEY2hvi7PVOBZR2gAEXgroFzhfSIxih S7jB71kZVHIuQauqBoD464pfa8CM3aeFIM93SOON997BUykNIa0Cqjt6XLejTCK58 QtafYUlyvuyiNKugMg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from user-Inspiron-3493 ([42.104.188.46]) by mail.gmx.net (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1McY8T-1tzD1914Qv-00bb8p; Sun, 22 Dec 2024 12:39:27 +0100 In-Reply-To: <87y10alqe5.fsf@> ("=?UTF-8?Q?Bj=C3=B6rn?= Bidar"'s message of "Fri, 20 Dec 2024 10:17:38 +0200") X-Provags-ID: V03:K1:TPrI7ERlMrzc3Ye9MtI9Y3QUWp1ZJg8wvRhKIIpGUkX4m1d42RH B/9R7bRb971VH3zhetjSG5i7DprupFQ9cGwEUGIrqgyuQf2oth5FnRajEeU0JocSNgyzCcp jxIKwSLiNj59w4itSCUNWYM8Jcr7k1JaYtfgSVo6oooQ6pOLb+4IP74VFOf9K7yVdKNV6LJ NqfTsJQZVpwoKD6dgsl7A== UI-OutboundReport: notjunk:1;M01:P0:o6uZATBlXtQ=;CS3dRPugm9RDqGnaWJEsc7P0smc v4+7vO+/Nr4XgpMZADPqfmMYN42gb9DK7rqd/9W7bYo7YsOTKRYQnCpD3Dy4YmhAH2LUKif5k YJheL4sz2/kVUOOhUTWhBcx+ttrKfhLSerqX3GdAlj6IouaCZIjPAU51WFBdjXjdEqhsZSdmU 8DXXS7xcLAAOUaWtpS9OtPem3jlX3Wr7bSYWahcP3s1uVh8oI2b3cvCPB1rtoMAcEeT77CJOx d2IYyuQzvFmPczdsEr4R3WhDRSauV3gja9flEltZ9KHqmD5bgpBMZnkorgyayGlxl+m/9l3Be jdznP3+e6OMLy7wqfQ711ZbjWIl9yD5+6JeOgPPCl1KpQ5L0Vq03MgQK+30abnS6aJschOgBa MgbZAjVr4I+zxn5jVyMIDDanR9YOHXd1v7a9A+DvSytCCaVhs6feY9PaEXcHVXmR/Aw/xl92D Tz/dhTRxgP7G5hQDNJa95GhmcoG3fZkfCcPxxmK4TPBUX4e/2qUo39aOTK+IRbLM9bKwCaUb6 rUOkUSw6BmuBoUGMv9n+NHSyIw62MaWOCSNFqxPK/dUx7iyu4g9fEXO4rhgXMaoZj4Axv+GVp DKiyQPm9hwjB7eBNNPRyFbQZBdiC/UsOhvBtuHXpHUNKI+6kX6P/Ts1Z9+7TeAbn3hXrb33cn 7IUXkwrEdSayTKy6WVqtBaQHV2m2Hcy2K965a35vPyducPECS9dY+RC6Rp62NX3r3SeBVEvFI v6+8QSW7V2uZLoAS3LqkrKIK9gzX3IjZ5MN/EtQ7+YbFpU7RJA3znl5fC5nSd39pilk6QFJU X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297589 Archived-At: Bj=C3=B6rn Bidar wrote: > James Thomas writes: > >> Bj=C3=B6rn Bidar wrote: >> >>> James Thomas writes: >>> >>>> James Thomas wrote: >>>> >>>>> Bj=C3=B6rn Bidar wrote: >>>>> >>>>>> James Thomas writes: >>>>>> >>>>>>> Bj=C3=B6rn 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? > > It does mimic it's operation or doesn't it? I mean, I was asking if it _should_ or not. I think it would be a good idea to get some 'grep'ed evidence of code coverage that -request-list would not supplant the intentions of -request-group. >>> 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. A= nd >>>> 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? > It only has one group containing other groups yes. The backend is not > supposed to end up in the Server but is only there if it falsely was > added to the select-methods. > > Anyway I need a backtrace from the case where the search did not work > with nnml groups. No no, you misunderstand me: It was just to demonstrate that: > that isn't the intended way of using nnvirtual ...can't be said. So please re-verify anything (there might've been) about the patch predicated on that. I did not encounter errors. I know you're exploiting the fact that the server and group are one, but perhaps it's being too clever by half. Any such unintended effects of that easy road ought to be acceptable to other users. I don't have any other misgivings, personally (on the face of it, i.e.: I haven't tested it well). --