From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.help Subject: Re: Gnus: Thread notes? Date: Tue, 12 Dec 2017 09:17:46 -0800 Message-ID: <874lovrhl1.fsf@ericabrahamsen.net> References: <87o9pc359b.fsf@web.de> <874lr3pz2q.fsf@ericabrahamsen.net> <87o9p6zy4f.fsf@web.de> <878tgavoio.fsf@ericabrahamsen.net> <87fu93ulhz.fsf@web.de> <87o9nq50hi.fsf@ericabrahamsen.net> <877eudsj2x.fsf@web.de> <874lpfjgb2.fsf@ericabrahamsen.net> <87indv6iup.fsf@web.de> <87wp2agxo5.fsf@ericabrahamsen.net> <87mv2om8tj.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1513099139 5767 195.159.176.226 (12 Dec 2017 17:18:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 12 Dec 2017 17:18:59 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Dec 12 18:18:55 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eOoCl-0001GY-BY for geh-help-gnu-emacs@m.gmane.org; Tue, 12 Dec 2017 18:18:55 +0100 Original-Received: from localhost ([::1]:59645 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOoCs-0005Z3-Jj for geh-help-gnu-emacs@m.gmane.org; Tue, 12 Dec 2017 12:19:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOoBu-0005Rp-62 for help-gnu-emacs@gnu.org; Tue, 12 Dec 2017 12:18:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eOoBp-0007Ex-7L for help-gnu-emacs@gnu.org; Tue, 12 Dec 2017 12:18:02 -0500 Original-Received: from [195.159.176.226] (port=57816 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eOoBp-0007Cz-0v for help-gnu-emacs@gnu.org; Tue, 12 Dec 2017 12:17:57 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eOoBe-0006Py-0i for help-gnu-emacs@gnu.org; Tue, 12 Dec 2017 18:17:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:TCEvw93+QD9Z+rmew6eVeoaA0go= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:115340 Archived-At: Michael Heerdegen writes: [...] > I think you could factor this defun so that it would be possible to set > `gnus-alter-articles-to-read-function' to one factor, then AFAICT, > automatic listing of tracked messages should be possible. Interesting! I'd never looked at that option before. I'd still like to keep the manual command, for those who don't want this to happen automatically, but yes, it wouldn't be hard to refactor. It would also require some sort of internal caching first -- right now it's too slow to have it running each time you enter a group. > If you care about Gnus, two things that came to my mind when fiddling > with this stuff: > > (1) I think `gnus-alter-articles-to-read-function' should better default > to a function (lambda (_group-name article-list) article-list), not to > nil, so that one could use `add-function' on it. Or the code could coerce the value to a list, and map all the functions. Maybe that would be more intuitive than `add-function'? > (2) (info "(gnus) Store arbitrary data") is missing a function that can > be used to delete the entry of a key for an ID. One can only associate > a key to nil, but that doesn't remove the association from the database; > it still contains the association key -> nil for ID. The idea with the registry is that it's sort of a catch-all slush bucket. I think it's expected that it will fill up rather quickly, and then get pruned as necessary. Ie, I don't think it matters that there are useless associations in there, only that "precious" associations aren't pruned. I've been thinking for a while about providing the option to have Gnorb use a separate registry. The way the registry works now, there's so much churn it's not really feasible to keep it in version control. Eric