From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6419 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Blue (or was it yellow?) GNUS suggestions Date: 28 May 1996 21:52:11 +0200 Message-ID: References: <199605252131.RAA00636@atreides> <199605280045.UAA00274@atreides> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146877 3524 80.91.224.250 (20 Oct 2002 20:47:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:47:57 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id OAA19021 for ; Tue, 28 May 1996 14:08:40 -0700 Original-Received: from eistla.ifi.uio.no (4867@eistla.ifi.uio.no [129.240.94.29]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 28 May 1996 21:59:32 +0200 Original-Received: (from larsi@localhost) by eistla.ifi.uio.no ; Tue, 28 May 1996 21:59:29 +0200 Original-To: ding@ifi.uio.no In-Reply-To: Sudish Joseph's message of Mon, 27 May 1996 20:45:21 -0400 Original-Lines: 47 X-Mailer: Gnus v5.2.2/Emacs 19.29 Xref: main.gmane.org gmane.emacs.gnus.general:6419 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6419 Sudish Joseph writes: > How about letting the user decide when to update the cached file? > We could store the date of the last update in the cache itself, > maintaining this date separately from the date used for the current > NEWGROUPS stuff? I.e., view the cache as a generic local copy of > the active file, to be used whenever we need to know the names of > all newsgroups--no need to tie it in with killed groups/new > groups/etc. That's a possibility. Or the cache could be updated when the list of killed groups reach a certain length or something. I've added this to the Red Gnus todo list. > While this would be very cool in itself, I was thinking more in terms > of rewriting the core thread/summary code as a loop that checks the > buffer associated with the NNTP connection, sees if any new headers > have arrived, slurps all new headers in a list, generates/updates > current threads/summary info for that list, then loops back to check > the nntp buffer, etc. That sounds very complicated. And is it useful? How many new articles typically arrive for the group you're reading while you're reading the group? > Anyways, having a separate process actually generate thread info would > be very cool, too. I looked into having mthreads (comes with trn, or > used to) generate lisp output (even text would be nice, instead of > it's current binary madness) about 14 - 16 months back--it's not hard > to do, the code is well commented. I had it outputting summaries on > threads very quickly. It would need to be rewritten to be > demand-driven rather than run as a daemon (I think that was how it was > coded, but it's been a long while.) I don't quite see how Gnus would be helped by this. The way Gnus threads things is highly user-customizable (gathering, fuzzy subject comparison, sparse nodes, ancient articles, ad nauseam). If we had a separate process spewing out the threads at us, then we'd lose that Lispish extensibility. Anyways, the threading itself is no problem. The most time spent is used to generate the summary buffer, and there no external process can help us. -- "Yes. The journey through the human heart would have to wait until some other time."