From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87445 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 09:32:51 -0700 Message-ID: <871stkq9qk.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490546061 25498 195.159.176.226 (26 Mar 2017 16:34:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Mar 2017 16:34:21 +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+m35666@lists.math.uh.edu Sun Mar 26 18:34:17 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 1csB7M-0005c3-K0 for ding-account@gmane.org; Sun, 26 Mar 2017 18:34:12 +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 0cfd1920-1242-11e7-b087-b499baabecb2; Sun, 26 Mar 2017 16:34:15 +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 1csB6h-0006Rt-OM; Sun, 26 Mar 2017 11:33:31 -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 1csB6e-0006RL-VX for ding@lists.math.uh.edu; Sun, 26 Mar 2017 11:33:29 -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 1csB6d-0006kg-TS for ding@lists.math.uh.edu; Sun, 26 Mar 2017 11:33:28 -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 1csB6c-00088Z-Gl for ding@gnus.org; Sun, 26 Mar 2017 18:33:26 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1csB6Q-0008J1-1I for ding@gnus.org; Sun, 26 Mar 2017 18:33:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 69 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:hCVpUq+5F8o3rpTkh0yS9i6NbuI= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87445 Archived-At: Andrew Cohen writes: [...] > The new feature (permanent search groups with full marks propagation) > can be explored as follows (I didn't add the code to make it > particularly user friendly when I introduced it and then got too busy to > do much more): > > Do an nnir search as you normally would (e.g. "G G" in the Group > buffer). While in the nnir Summary buffer invoke the command > 'gnus-summary-create-nnir-group. This will prompt for a name and create > a group using the search parameters that yielded the nnir summary > buffer. This Group should then show up in the Group buffer. You can > modify the search by editing the Group parameters (e.g. "G p" on the > group in the Group buffer). This group behaves (almost) like any other > Gnus group, and marks should propagate as you would expect. Very cool! I never noticed `gnus-summary-create-nnir-group' down at the bottom of the file. So far as I can see, the only remaining pieces would be to give that command a gnus-group-mode keybinding, and have it prompt for a query, rather than taking the query from the current group. If at present it's necessary to prefix the group name with "nnir-", that can simply be done unconditionally in the command. That's it, isn't it? That and documentation, of course. I'd be happy to help with completing this, and/or documenting it. [...] > 5. Unfortunately "virtual" has already been used in Gnus to mean > something else so I can't call these groups (created from messages > spread out across real groups) virtual. I have been (in my head) > calling them "select" groups. > > Finally I should say that when I rewrote nnir from scratch I > deliberately separated out the "searching" part from the message and > group handling part to allow this. Everything is more or less factored > out and my plan was to create an "nnselect" backend that includes all of > the non-searching parts and just uses a group parameter to specify which > articles should be included in the group. This parameter could, for > example, be an nnir search query; or it could be any function that > returns a list of articles in an appropriate format (this format is also > described in nnir.el). Everything is in place to do this (its probably > an afternoon's work to rename and move the pieces around) but I just > haven't found time to do so. I dove pretty deeply into nnir a year or two ago when I was writing Gnorb. I needed exactly what you describe here: a simple way to create groups containing arbitrary messages. I ended up having to write a fake "nngnorb" backend, and require users to add it to their server list, because that was the only way nnir could find the correct query function to run. I would love to just be able to specify a function as part of the query parameter! As for the backends... It seems like there are too many backends already. Why don't we just hijack nnvirtual? nnselect sounds like it would be exactly like nnvirtual, except with the ability to specify articles in addition to groups. It would be more work to merge the two, but I think it would make much more sense all around. Virtual groups would be any kind of virtual group, and then there'd just be a search interface laid on top of it. What do you (or anyone else) think? Eric