From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/47503 Path: main.gmane.org!not-for-mail From: Wes Hardaker Newsgroups: gmane.emacs.gnus.general Subject: Re: overview -> .db files? Date: Thu, 31 Oct 2002 13:03:41 -0800 Organization: Network Associates Laboratories Sender: owner-ding@hpc.uh.edu Message-ID: References: <844rb2o4ef.fsf@crybaby.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1036098304 29098 80.91.224.249 (31 Oct 2002 21:05:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 31 Oct 2002 21:05:04 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 187MUv-0007Yu-00 for ; Thu, 31 Oct 2002 22:05:01 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 187MUF-0000EA-00; Thu, 31 Oct 2002 15:04:19 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 31 Oct 2002 15:05:04 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id PAA19778 for ; Thu, 31 Oct 2002 15:04:49 -0600 (CST) Original-Received: (qmail 7426 invoked by alias); 31 Oct 2002 21:03:53 -0000 Original-Received: (qmail 7420 invoked from network); 31 Oct 2002 21:03:53 -0000 Original-Received: from adsl-63-195-146-66.dsl.scrm01.pacbell.net (HELO localhost.localdomain) (@63.195.146.66) by gnus.org with SMTP; 31 Oct 2002 21:03:53 -0000 Original-Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id g9VL3fO02271; Thu, 31 Oct 2002 13:03:41 -0800 Original-To: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 In-Reply-To: <844rb2o4ef.fsf@crybaby.uni-duisburg.de> (kai.grossjohann@uni-duisburg.de's message of "Thu, 31 Oct 2002 19:21:44 +0100") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:47503 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:47503 >>>>> On Thu, 31 Oct 2002 19:21:44 +0100, kai.grossjohann@uni-duisburg.de (= Kai Gro=DFjohann) said: Kai> But I think there are already provisions for using headers Kai> instead of NOV format. So maybe that's a spot where you can hook Kai> in and return the headers to Gnus in a Lisp data structure Kai> without going via a buffer. Yeah, I realized it would likely affect both the place where Gnus and the backends were involved. Essentially functions would have to wrap access to NOV calls, and what the NOV calls did behind the scenes would either look stuff up in a list (as is now) or in a DB. Kai> It would be a major undertaking. Please work on it :-) Doubtful. I suspect it'd be a bit over my head with respect to gnus code. I'm sure I could do it, but the undertaking would be even larger for me ;-) Kai> Another possibility which might be easier is to keep the backend Kai> interface and to just use the db files as a faster way to extract Kai> the right headers. Yeah, I thought of that as well. Actually, just making the overview files be .el files would probably be a big win. Kai> At least for me, the slow part about using Gnus is the generation of Kai> the summary buffer. I wonder if that can be made faster somehow. Yeah. The patch I wrote a while ago to display the summary buffer as it's building it is a good thing, because it lets you view stuff to at least keep you occupied while it's building. (I've been bugging my boss about his half of the assignment rights for it as well as the nnsf code, but he's a busy guy) Kai> Is there a way to create a buffer with a lot of text properties and Kai> stuff really quickly? What happens if we princ (buffer-string) to a Kai> file and then read that representation into memory and use a single Kai> insert call to create a buffer from it? That's worth trying. I've often thought that on exiting a summary buffer, you have all the display information since you've already created it, so couldn't we save the current buffer to a file, reload it and reapply all the regions and insert new contents? That *may* be faster than rebuilding it from scratch every time. --=20 "The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it." -- Terry Pratche= tt