From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/47513 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: overview -> .db files? Date: Fri, 01 Nov 2002 18:42:47 +0100 Organization: University of Dortmund, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <84fzulnq3s.fsf@crybaby.uni-duisburg.de> 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: 8bit X-Trace: main.gmane.org 1036172592 31935 80.91.224.249 (1 Nov 2002 17:43:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 1 Nov 2002 17:43:12 +0000 (UTC) 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 187fp6-0008IW-00 for ; Fri, 01 Nov 2002 18:43:08 +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 187fpD-0002gz-00; Fri, 01 Nov 2002 11:43:15 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 01 Nov 2002 11:43:59 -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 LAA23688 for ; Fri, 1 Nov 2002 11:43:42 -0600 (CST) Original-Received: (qmail 2160 invoked by alias); 1 Nov 2002 17:42:52 -0000 Original-Received: (qmail 2155 invoked from network); 1 Nov 2002 17:42:52 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by gnus.org with SMTP; 1 Nov 2002 17:42:52 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 187ftg-0005KN-00 for ; Fri, 01 Nov 2002 18:47:52 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 68 Original-NNTP-Posting-Host: pd9e1e75a.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1036172871 20473 217.225.231.90 (1 Nov 2002 17:47:51 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 1 Nov 2002 17:47:51 GMT User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) Cancel-Lock: sha1:8EwihjhF2BNoUSS62QM4ivpotzw= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:47513 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:47513 Wes Hardaker writes: >>>>>> On Thu, 31 Oct 2002 19:21:44 +0100, kai.grossjohann@uni-duisburg.de (Kai Großjohann) 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. Ah, you had in mind the *right* solution :-) > 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 ;-) Not all of us can be expected to be gurus like Lars and ShengHuo :-) I admire those who grok the Gnus code. > 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. Indeed. Ah, that could be a first step. I don't know, however, if Gnus sometimes looks at parts of the overview file only. > 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) Oh yes, I think I wanted to install that. > 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. Yes, inserting the new information might be possible if you look at how `/ N' and `/ O' do it. kai -- ~/.signature is: umop ap!sdn (Frank Nobis)