From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85185 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: Sat, 25 Oct 2014 12:59:38 -0700 Message-ID: <87mw8j9az9.fsf@ericabrahamsen.net> References: <87egtx70hy.fsf@ericabrahamsen.net> <87ppdhyynb.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414266957 3719 80.91.229.3 (25 Oct 2014 19:55:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Oct 2014 19:55:57 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33429@lists.math.uh.edu Sat Oct 25 21:55: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 1Xi7RE-0006Wl-KV for ding-account@gmane.org; Sat, 25 Oct 2014 21:55:48 +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 1Xi7QO-0001B9-6c; Sat, 25 Oct 2014 14:54:56 -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 1Xi7QK-0001Ag-Ro for ding@lists.math.uh.edu; Sat, 25 Oct 2014 14:54:52 -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 1Xi7QJ-00010K-EN for ding@lists.math.uh.edu; Sat, 25 Oct 2014 14:54:52 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1Xi7QH-00061A-3p for ding@gnus.org; Sat, 25 Oct 2014 21:54:49 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xi7QC-00062F-4A for ding@gnus.org; Sat, 25 Oct 2014 21:54:44 +0200 Original-Received: from 63.226.249.211 ([63.226.249.211]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Oct 2014 21:54:43 +0200 Original-Received: from eric by 63.226.249.211 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Oct 2014 21:54:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 63.226.249.211 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:YHzMEAjejYPKIxollDboXclqiB0= X-Spam-Score: -3.2 (---) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85185 Archived-At: Eric Abrahamsen writes: > 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. Given the commentary in registry.el, I wonder if the whole pruning arrangement actually never quite got finished: ;; The user decides which fields are "precious", F2 for example. At ;; PRUNE TIME (when the :prune-function is called), the registry will ;; trim any entries without the F2 field until the size is :max-soft ;; or less. No entries with the F2 field will be removed at PRUNE ;; TIME. It looks like there's supposed to be a :prune-function slot on registry objects, and presumably the Gnus registry would have a prune function that worked more like what the comments above outline. I'd be happy to help work on this, with a little direction... Eric