From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87446 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus nnmaildir and notmuch Date: Mon, 27 Mar 2017 09:09:51 +0800 Organization: Boston University Message-ID: <87fuhzsexs.fsf@hanan.ust.hk> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490586172 3821 195.159.176.226 (27 Mar 2017 03:42:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 03:42:52 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+m35667@lists.math.uh.edu Mon Mar 27 05:42:48 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048034.atla03.us.yomura.com ([107.189.48.34]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csLYK-0008KK-Ae for ding-account@gmane.org; Mon, 27 Mar 2017 05:42:44 +0200 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048034.atla03.us.yomura.com (Halon) with ESMTPS id 71847505-129f-11e7-8ed1-b499baa2b07a; Mon, 27 Mar 2017 03:42:47 +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 1csJAs-0001uT-VQ; Sun, 26 Mar 2017 20:10:23 -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 1csJAq-0001tl-0R for ding@lists.math.uh.edu; Sun, 26 Mar 2017 20:10:20 -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 1csJAo-00013K-Su for ding@lists.math.uh.edu; Sun, 26 Mar 2017 20:10:19 -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 1csJAn-0004xf-Fh for ding@gnus.org; Mon, 27 Mar 2017 03:10:17 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1csJAZ-0003Fh-C0 for ding@gnus.org; Mon, 27 Mar 2017 03:10:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 63 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:/9SH0IMFsKaSibfN4RpkdZlJbL4= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87446 Archived-At: >>>>> "Eric" == Eric Abrahamsen writes: [...] Eric> So far as I can see, the only remaining pieces would be to Eric> give that command a gnus-group-mode keybinding, and have it Eric> prompt for a query, rather than taking the query from the Eric> current group. If at present it's necessary to prefix the Eric> group name with "nnir-", that can simply be done Eric> unconditionally in the command. Eric> That's it, isn't it? That and documentation, of course. I'd be Eric> happy to help with completing this, and/or documenting it. 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...) [...] Eric> I dove pretty deeply into nnir a year or two ago when I was Eric> writing Gnorb. I needed exactly what you describe here: a Eric> simple way to create groups containing arbitrary messages. I Eric> ended up having to write a fake "nngnorb" backend, and require Eric> users to add it to their server list, because that was the Eric> only way nnir could find the correct query function to run. I Eric> would love to just be able to specify a function as part of Eric> the query parameter! This is also already done in my personal version. 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. (And a small mea culpa---looks like I DID add expiry but just disabled it for myself. It was so long ago I've mostly forgotten what I did :)) Andy