From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87443 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus nnmaildir and notmuch Date: Sun, 26 Mar 2017 12:51:59 +0800 Organization: Boston University Message-ID: <87r31kzllc.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490504010 29465 195.159.176.226 (26 Mar 2017 04:53:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Mar 2017 04:53:30 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+m35664@lists.math.uh.edu Sun Mar 26 06:53:26 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 1cs0BB-0006yC-1N for ding-account@gmane.org; Sun, 26 Mar 2017 06:53:25 +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 26b2f6ce-11e0-11e7-8ed1-b499baa2b07a; Sun, 26 Mar 2017 04:53:28 +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 1cs0AI-00019V-LA; Sat, 25 Mar 2017 23:52:30 -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 1cs0AF-00018g-FZ for ding@lists.math.uh.edu; Sat, 25 Mar 2017 23:52:27 -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 1cs0AE-0003cb-7z for ding@lists.math.uh.edu; Sat, 25 Mar 2017 23:52:27 -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 1cs0AC-0000wE-Rg for ding@gnus.org; Sun, 26 Mar 2017 06:52:24 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cs09t-0007k1-Ht for ding@gnus.org; Sun, 26 Mar 2017 06:52:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 113 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:PUNXZ2aO7EpuVcCWV+nEDG0w3rQ= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87443 Archived-At: >>>>> "Eric" == Eric Abrahamsen writes: [...] Eric> Andy, I wonder if any of your local changes affect this Eric> behavior? Sorry, I sent a reply to the other Erik but didn't cc the list. The behavior is intentional. As you learned, ephemeral groups explicitly do not propagate marks. And nnir searches are ephemeral. But as you also discovered nnir has the necessary code to propagate marks. This is because it allows for non-ephemeral search groups as well. I sent a message to this list about this feature several years ago. 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. For example I have a group that finds all of my "flagged" messages. For reference the group parameters for this search include: (nnir-specs (nnir-query-spec (query . "FLAGGED") (criteria . "")) (nnir-group-spec ("nnimap:home"))) This searches for all the flagged message on my nnimap:home server and creates a a group out of the results. (It currently has over a thousand messages:() I also have a bunch of groups for certain correspondents; and groups for messages in certain date ranges. And a variety of others. In fact these "virtual" search groups are probably the primary way I have been using gnus for the past few years. Although I haven't done it yet, I keep thinking I should stop moving my email around and keep it all in a single inbox and then just use these permanent search groups instead. I made the decision at the time that regular searches should properly be ephemeral and not propagate marks. (And while modifying the quit-config parameter on an ephemeral group mostly works there are some gotchas that make it not by itself a good solution). But "permanent" search groups should behave more, uhm, permanently. There are a few wrinkles to be aware of: 1. Since searching can be slow I chose to not redo the search on every scan and use a cached search result. You can always force a hard rescan. (This could be managed by using levels to avoid scanning on groups that are slow to scan instead.) 2. These permanent groups don't do expiry. Expiry is tricky for groups whose messages are aggregated from different sources: some of the sources may not support expiry; should the search group have its own expiry parameters or rely on the expiry rules from each article's home group? Since expiry rules often rely on time information, whose time? The search group or the home group? Of course choices could be made but I think any choice would lead to some surprises so I chose to not use it. (I visit the home groups of most articles in my virtual groups not infrequently and these home groups have their own expiry rules that then get applied). 3. Gnus sometimes gets confused about how many articles are in the virtual group and how many are unread. I never found it annoying enough to track down but there are still bugs in this regard. 4. The interface isn't very user friendly. (Actually it works pretty well---if you are conversant in raw imap search format. To make a new group I just do a random search, create the group, and then edit the group parameter to put in my properly crafted imap search query. The formats of the nnir-query-spec and nnir-group-spec are documented in nnir.el) 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. Best, Andy