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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7736 invoked from network); 9 Sep 2020 03:27:26 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 9 Sep 2020 03:27:26 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1kFqlG-00CpGm-9O; Tue, 08 Sep 2020 22:27:06 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kFqlC-00CpEk-Ij for ding@lists.math.uh.edu; Tue, 08 Sep 2020 22:27:02 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kFqkd-008pFf-1H for ding@lists.math.uh.edu; Tue, 08 Sep 2020 22:27:02 -0500 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=6nuyrDt8SkS4qidbvCPyG7XJQmxGX7/GVLhsFP1GQ6s=; b=VRvaz7Dl7HLqvW0zpDN9SH/4fR /IkDP1ZwdLwTpk3JLZFlje090pINfbU9c2+ecjenlrB9nTln0ZtkcotcdOo0Hj1NCJ7Z1GXGYMAz4 SNrL70E+GJgbzrjkUa+7Ki4B4G+nd5srVjj9eygw9mWe3fjLXkEFBblkFmdqtSQOge8k=; Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214] helo=ciao.gmane.io) by quimby with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFqkT-00043Z-Se for ding@gnus.org; Wed, 09 Sep 2020 05:26:22 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kFqkS-0001Cr-0j for ding@gnus.org; Wed, 09 Sep 2020 05:26:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Andrew Cohen Subject: Re: useful things with nnselect Date: Wed, 09 Sep 2020 11:26:05 +0800 Message-ID: <87k0x3y6k2.fsf@ust.hk> References: <87imcp9ha5.fsf@ust.hk> <878sdj4plv.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:VYb9MN/6QMIsfBb/Q9zYdZ8Ofrg= List-ID: Precedence: bulk >>>>> "EA" == Eric Abrahamsen writes: [...] EA> I'd be curious to hear how this differs from nnir -- as far as I EA> know, these things were mostly already possible with nnir, EA> right? In fact, no, most of these things weren't possible with nnir. Firstly, nnir is (or I mean, used to be :)) a combination of two things: searching, and glue to make the result of a search work as a gnus group. This glue didn't allow for persistent groups, only ephemeral ones (well, a long time ago I hacked something in to kind of allow it, but the resulting groups didn't work like regular gnus groups and had significant limitations). Also, nnir didn't originally contain any of the logic to make changes in these groups permanent (again, I have over time added more and more of this functionality, but it was never complete). The point of nnselect was to cleanly separate the searching (which is in nnir) from what to do with the list of matches that searching returns. nnselect is now a first-class backend---nnselect groups should behave like any other group (can be persistent or ephemeral; all marks, changes, etc are supported). Also, nnselect groups don't have to come from an nnir search. The Todo group I described has nothing to do with searches and nnir isn't used. I have a variety of groups like this that I didn't describe because they are kind of niche. But nnselect makes this possible. EA> FWIW, I'm most excited about nnselect as a hacker, as it allows EA> you to decouple the search process from the servers altogether EA> -- nnir required all searches to *start* with one or more EA> servers, while nnselect lets you approach the thing in a more EA> ad-hoc fashion. Yes, that is the point---decoupling the search from anything gnus-specific, and allowing the search to be its own thing (which allows it to be server-neutral). EA> One thing I'm noticing now (sorry I didn't see this earlier!) is EA> that ephemeral search groups don't seem 100% ephemeral: I've EA> searched using "G G" in the Groups buffer and "G" in the Server EA> buffer, and while the search groups are no longer visible when I EA> leave them, they seem to be updating when I hit "g" to update EA> everything later on: I get a bunch of Messages about EA> re-searching the groups that were part of the earlier search EA> groups. This sounds like a bug, and isn't happening for me. When closing one of these groups this should happen: (when (gnus-ephemeral-group-p group) (gnus-kill-ephemeral-group group) (setq gnus-ephemeral-servers (assq-delete-all 'nnselect gnus-ephemeral-servers))) So the ephemeral group should be really, truly, gone after exit.