From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85183 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] Two issues with the gnus-registry Date: Fri, 24 Oct 2014 13:56:56 -0700 Message-ID: <87ppdhyynb.fsf@ericabrahamsen.net> References: <87egtx70hy.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414183977 18204 80.91.229.3 (24 Oct 2014 20:52:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2014 20:52:57 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33427@lists.math.uh.edu Fri Oct 24 22:52:50 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 1Xhlqr-000213-VP for ding-account@gmane.org; Fri, 24 Oct 2014 22:52:50 +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 1XhlqG-0003gw-9J; Fri, 24 Oct 2014 15:52:12 -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 1XhlqC-0003gK-Ni for ding@lists.math.uh.edu; Fri, 24 Oct 2014 15:52:08 -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 1XhlqB-0005O8-7p for ding@lists.math.uh.edu; Fri, 24 Oct 2014 15:52:08 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1Xhlq9-0000fF-8P for ding@gnus.org; Fri, 24 Oct 2014 22:52:05 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xhlq7-0001gZ-US for ding@gnus.org; Fri, 24 Oct 2014 22:52:03 +0200 Original-Received: from c-76-28-195-250.hsd1.wa.comcast.net ([76.28.195.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Oct 2014 22:52:03 +0200 Original-Received: from eric by c-76-28-195-250.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Oct 2014 22:52:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-76-28-195-250.hsd1.wa.comcast.net User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:K/6fDncds4I5Ln0QNhtuqmDRCV0= X-Spam-Score: -4.3 (----) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85183 Archived-At: Eric Abrahamsen writes: > Hi there, > > I'm using the gnus-registry in Gnorb to keep track of correspondences > between Gnus messages and Org headings, using a key on the registry > entries called 'gnorb-ids. This is meant to be a "precious" key, ie > entries with this key are not pruned. So far so good: > > (oref gnus-registry-db :precious) => (gnorb-ids mark) > > But the entries still do get pruned! I've just had tracked entries start > disappearing on me, and realized that they're getting pruned from the > registry when I save it. There appear to be two problems here: [...] > And I really don't know why the precious entries are getting pruned. > In a day or so, when I have more time, I'll test with a dummy registry, > with max-entries set to 10 and 'creation-time added to the precious > entries -- should make debugging easier. Okay, I got curious (frustrated) and tried this, and I just don't get it. `registry-prune' doesn't seem to work as advertised: first it deletes according to `registry-prune-soft-candidates', which preserves precious entries, and then it deletes according to `registry-prune-hard-candidates', which doesn't.p The second pass unconditionally caps the registry length at 90% of `gnus-registry-max-entries', without consulting the entries' precious status at all. The `prune-needed' local variable also appears unused. My understanding of the process is that the two functions should create their two separate sets (entries over 90% of `gnus-registry-max-entries', and non-precious entries), and then the intersection of those two sets should be deleted. Done this way, sorting would be cheaper as well -- you'd only need to sort candidates by age for the hard-prune set. I'm still pretty confused, but I can prepare a patch for this. Perhaps I'm misreading the code, but I can't see how! Eric