From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22356 invoked from network); 4 Mar 2022 17:28:30 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 4 Mar 2022 17:28:30 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nQBjB-00AI3q-Ae for ml@inbox.vuxu.org; Fri, 04 Mar 2022 11:28:29 -0600 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94.2) (envelope-from ) id 1nQBjA-00589D-K0 for ml@inbox.vuxu.org; Fri, 04 Mar 2022 11:28:28 -0600 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1nQBj9-005896-8o for ding@lists.math.uh.edu; Fri, 04 Mar 2022 11:28:27 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nQBj7-00Gs2i-B3 for ding@lists.math.uh.edu; Fri, 04 Mar 2022 11:28:26 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:References:Message-ID:Date:Subject: From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=N75mAqK+0R07rxLt5eL8uO56XEyHn8oWTZO8jkltEmU=; b=gJi23XD0b7SAsevFC7YrgMPcjk m9tOPd6Tr1Exij/ub8jur0OwwcihWGemAmxojapBCP7OFnptqEagxP9GbnpUdO8zdfKm2ifTOOK3t q02p0ueKHKJrdwgNkdl6jtdx4OsUqMDM3N4kZWm0eWKsOy+SCyBMtiJFtfTu1KIa0UOU=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQBj0-0007AX-H6 for ding@gnus.org; Fri, 04 Mar 2022 18:28:20 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nQBiz-0003hF-7o for ding@gnus.org; Fri, 04 Mar 2022 18:28:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: nnvirtual groups and article warping Date: Fri, 04 Mar 2022 09:28:09 -0800 Message-ID: <87pmn11vbq.fsf@ericabrahamsen.net> References: <87czj3x9gh.fsf@ucl.ac.uk> <8735jyygh2.fsf@ericabrahamsen.net> <87czj27hm4.fsf@ust.hk> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cancel-Lock: sha1:BTTc1d8HygMYuRTcMM95Zxh+Q4k= List-ID: Precedence: bulk Andrew Cohen writes: >>>>>> "EA" == Eric Abrahamsen writes: > > EA> Eric Abrahamsen writes > > [...] > > EA> The weird thing, poking into the code, is that no backends seem > EA> to implement *-warp-to-article, except nnselect. Doesn't that > EA> seem weird? > > Err, no? Aside from nnselect and nnvirtual, every article is already in > its original group so warping should be a no-op. > > I added warping early on to nnir simply because nnir was completely > ephemeral: that is, no changes made would propagate back to the original > article (i.e. if you wanted to tick an article it wouldn't stick if you > did so after a search---warping was a hack to deal with that). Now that > nnselect does everything a regular backend does, there shouldn't be much > use for warping. I guess it just struck me as odd that there's a whole backend deffoo for it, when it's only used in one place. Some of the earlier code commits mention using it for nndoc, but it looks like that never happened. > I never used nnvirtual so I never made changes for it. I see no reason > NOT to add a warping for nnvirtual which should be straightforward (as > you describe below). But I am curious what the use case is? nnvirtual > already does (some) propagation back to the originating groups. > > (BTW I think the stuff I posted some weeks ago does pretty well at > replacing nnvirtual in nnselect. I haven't tested it very much but if it > lacks something I can look into it). I agree that there's less and less need for nnvirtual, but also that there's no harm in adding an `nnvirtual-warp-to-article' deffoo, for completeness' sake. I was going to bring this up again, regarding full nnvirtual feature coverage for nnselect: Eric F's original query was about using nnselect exactly as nnvirtual is used: you add the component groups, put in *no* specification about which articles to display, and then when you enter the select group it simply shows you all articles from the component groups. (I've never looked closely at the nnvirtual code and I don't know how it decides which articles to draw from which component groups. If none of the groups have unread articles, and you request 100 articles from the virtual group, how does it handle sorting and limiting?) Anyway, I spent twenty minutes or so trying to come up with a nnselect-spec that would do this, and failed. If you could point out how we'd go about this, then I think we could say nnselect has a full superset of nnvirtual functionality. Eric