From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85172 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus uses a cache? And how it affects mairix searches... Date: Wed, 22 Oct 2014 16:30:32 +0800 Message-ID: <87d29ka4lz.fsf@ericabrahamsen.net> References: <87oaus4brr.fsf@skimble.plus.com> <8761gyvr67.fsf_-_@uwo.ca> <87y4saicdd.fsf@uwo.ca> <877fzu1ehs.fsf@ericabrahamsen.net> <87r3y0a6l2.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413966376 18660 80.91.229.3 (22 Oct 2014 08:26:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Oct 2014 08:26:16 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33416@lists.math.uh.edu Wed Oct 22 10:26:09 2014 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XgrF8-0000Rn-Bl for ding-account@gmane.org; Wed, 22 Oct 2014 10:26:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1XgrEq-0004a0-Bn; Wed, 22 Oct 2014 03:25:48 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1XgrEm-0004ZT-VH for ding@lists.math.uh.edu; Wed, 22 Oct 2014 03:25:44 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1XgrEl-0004U4-Ci for ding@lists.math.uh.edu; Wed, 22 Oct 2014 03:25:44 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1XgrEj-0002UZ-R6 for ding@gnus.org; Wed, 22 Oct 2014 10:25:41 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XgrEi-0000Ih-Rd for ding@gnus.org; Wed, 22 Oct 2014 10:25:40 +0200 Original-Received: from 111.199.149.147 ([111.199.149.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Oct 2014 10:25:40 +0200 Original-Received: from eric by 111.199.149.147 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Oct 2014 10:25:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 64 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 111.199.149.147 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:dyuoyMmvkpNqcwAWgaatj9d03LA= X-Spam-Score: -3.2 (---) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85172 Archived-At: Eric Abrahamsen writes: > Eric Abrahamsen writes: > >> Dan Christensen writes: >> >>> Dan Christensen writes: >>> >>>> [Sorry to hijack the thread. Subject adjusted.] >>>> >>>> James Cloos writes: >>>> >>>>> There is some caching of articles w/in a given session, but nothing I'm >>>>> aware of which would survive a restart. >>>> >>>> Since upgrading Ubuntu and Gnus, I've noticed that the results of >>>> nnmairix searches infiltrate subsequent search results. More precisely, >>>> the second time I do a search, the summary buffer looks correct, but for >>>> some of the articles, when I select them the *Article* buffer shows the >>>> articles from the previous search. The third search may show article >>>> buffers from the first or second search (or both). >>>> >>>> My search results are stored in a local imap folder (dovecot), and I >>>> have verified that on disk the correct articles are stored. I have also >>>> verified that if I connect to dovecot via telnet, it displays the >>>> correct article bodies. I am not using the agent (as far as I know). >>>> >>>> I have also tried various nnmairix keystrokes to redo searches, etc, >>>> and none of them helped. >>>> >>>> Any idea why this is happening? nnmairix used to work beautifully for >>>> me. >>>> >>>> Dan >>> >>> I finally figured this out. Setting gnus-keep-backlog to nil solved >>> the problem. It turns out that by default, gnus caches the most recent >>> 20 articles you have viewed, rather than contacting the server again. >>> This is true even if you exit and reenter a summary buffer. >>> >>> Maybe nnmairix should remove articles from this cache when it creates >>> a search folder? Or bind this variable to nil in nnmairix groups? >> >> Hmm, I may have seen this in nnir groups, as well. At least, I've (only >> once or twice) had a similar situation: selecting articles in an nnir >> search summary buffer, and seeing article bodies from the last search. I >> can only assume it's the same problem... > > Just had it again! See attachment -- the article body shown when > selecting one summary line actually belongs to a different summary line. > This time it seems fairly reproducible (and is messing with > Gnorb-related stuff) so I'll see if I figure it out, starting with > setting gnus-keep-backlog to 0. And yes, that worked. My guess is that gnus should just not enter articles into the backlog if they came from a search-composed group. Ie, the check at the very top of `gnus-backlog-enter-article' needs to be expanded. I thought that gnus-ephemeral-group-p might be the right check, but that doesn't flag nnir/nnmairix groups. I need to run out, but will look at this more later -- or if anyone knows a nice clean filter, rather than checking against a bunch of regexps? Eric