From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87447 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus nnmaildir and notmuch Date: Sun, 26 Mar 2017 21:33:36 -0700 Message-ID: <87efxjpcdb.fsf@ericabrahamsen.net> References: <87poh8nwxj.fsf@ecocode.net> <87shm3zeyf.fsf@hanan.ust.hk> <871stnrtn8.fsf@ecocode.net> <87mvcbqe18.fsf@ecocode.net> <87bmsrqdrl.fsf@ecocode.net> <87lgru7k15.fsf@ericabrahamsen.net> <8760iyfr66.fsf@ericabrahamsen.net> <87r31kzllc.fsf@hanan.ust.hk> <871stkq9qk.fsf@ericabrahamsen.net> <87fuhzsexs.fsf@hanan.ust.hk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490589315 19153 195.159.176.226 (27 Mar 2017 04:35:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 04:35:15 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+m35668@lists.math.uh.edu Mon Mar 27 06:35:11 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048035.atla03.us.yomura.com ([107.189.48.35]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csMN0-0004Ak-2u for ding-account@gmane.org; Mon, 27 Mar 2017 06:35:06 +0200 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048035.atla03.us.yomura.com (Halon) with ESMTPS id c271cf74-12a6-11e7-b087-b499baabecb2; Mon, 27 Mar 2017 04:35:09 +0000 (UTC) Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.87) (envelope-from ) id 1csMM6-0003SN-H5; Sun, 26 Mar 2017 23:34:10 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1csMM3-0003Rb-ID for ding@lists.math.uh.edu; Sun, 26 Mar 2017 23:34:07 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1csMM1-0002Dw-UW for ding@lists.math.uh.edu; Sun, 26 Mar 2017 23:34:07 -0500 Original-Received: from [195.159.176.226] (helo=blaine.gmane.org) by quimby.gnus.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1csMM0-0007CR-I8 for ding@gnus.org; Mon, 27 Mar 2017 06:34:04 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1csMLr-0005l8-6m for ding@gnus.org; Mon, 27 Mar 2017 06:33:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:41eYUhP0hMNowPQS6XmRZSK4xB8= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87447 Archived-At: Andrew Cohen writes: > Already done in my private version (sans documentation). But I don't > want to do it now since I'd rather finish the factoring I mentioned > previously. This factoring would lead to incompatible changes in > people's setups (mostly renaming, but still...) [...] > This is also already done in my personal version. Okay, looking forward to it! > Eric> As for the backends... It seems like there are too many > Eric> backends already. Why don't we just hijack nnvirtual? nnselect > Eric> sounds like it would be exactly like nnvirtual, except with > Eric> the ability to specify articles in addition to groups. It > Eric> would be more work to merge the two, but I think it would make > Eric> much more sense all around. Virtual groups would be any kind > Eric> of virtual group, and then there'd just be a search interface > Eric> laid on top of it. > > Merging with nnvirtual doesn't make any sense: the functionality of > nnvirtual (combining existing groups to act as a single group) can > already be done directly as part of nnselect. And the approach taken in > nnvirtual to doing this is radically different from the one I adopted > for nnir (which makes sense since most of the hard work in nnir doesn't > exist for merging entire groups). So the choice is to either eliminate > nnvirtual entirely and replace it with nnselect (possibly renaming in > the process) or let both co-exist. Since replacing it would break things > for anyone using it I favor leaving it alone (unless it turns out that > no one is using it). Over time we can then consider eliminating > nnvirtual. Sure, by "merging" I just meant that we don't need both of them -- I was also assuming that the code from nnir/nnselect would mostly replace nnvirtual. Co-existence is fine, though it will be confusing for people exploring Gnus. Perhaps if the docs emphasize nnselect, and only mention nnvirtual in terms of backwards compatibility, it wouldn't be a big deal. Eric