From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/31806 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: (provide 'nnmaildir) Date: Sun, 16 Jul 2000 17:34:38 -0400 (EDT) Organization: What did you have in mind? A short, blunt, human pyramid? Sender: owner-ding@hpc.uh.edu Message-ID: <20000716213439.11710.qmail@multivac.student.cwru.edu> References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1035168174 16130 80.91.224.250 (21 Oct 2002 02:42:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:42:54 +0000 (UTC) Return-Path: Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35]) by mailhost.sclp.com (Postfix) with ESMTP id 9E25BD051E for ; Sun, 16 Jul 2000 17:38:42 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id QAC18393; Sun, 16 Jul 2000 16:35:13 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 16 Jul 2000 16:34:17 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id QAA20336 for ; Sun, 16 Jul 2000 16:34:06 -0500 (CDT) Original-Received: from multivac.student.cwru.edu (multivac.STUDENT.CWRU.Edu [129.22.239.69]) by mailhost.sclp.com (Postfix) with SMTP id E689ED051E for ; Sun, 16 Jul 2000 17:34:40 -0400 (EDT) Original-Received: (qmail 11711 invoked by uid 500); 16 Jul 2000 21:34:39 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org In-Reply-To: X-Mailer: VM 6.75 under Emacs 20.7.1 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:31806 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:31806 There's a crude but working version of nnmaildir at . Feel free to have a look and take it for a spin, but there will be incompatible changes soon, so don't migrate just yet. - The server name is the group that mail shows up in. I know this is wrong now, so it'll change very soon - the server name will be treated as opaque data, and groups will be handled by something like nnmail-split-fancy. - Article numbers are sequential, starting from 1. When assigning numbers to new messages, nnmaildir-i-cur-max peeks at (among other things) gnus-newsrc-alist to get the highest article number known to Gnus. Can someone look at this and tell me if I did this right? - Problem: my .emacs contains (require 'nnmaildir), and after that, (setq nnmaildir-directory "~/var/mail"). nnmaildir.el contains (defvoo nnmaildir-directory "~/Maildir"). Before I start Gnus the first time, nnmaildir-directory has the value "~/var/mail", just like I want. But when I start Gnus, it looks in "~/Maildir" instead. Subsequently setting it back to my value doesn't help; it always gets changed back when I start Gnus. Any ideas? - This happened twice just now. I had 4 new messages (a different set of 4 messages in each of the two trials). I erased Gnus's memory of read articles for my mail group in my newsrc.eld. When I started Gnus, it said there were 4 new messages. When I selected the group, I saw all 4 messages in the summary buffer, but the first three were marked as old (`O'). When I quit the group without reading any messages, the group buffer said there was only 1 new message in that group. Hmm. Kai Gro=DFjohann writes: > I think doing the NOV thing is important to gain speed. The Gnus > backend interface heavily relies on the data contained in NOV lines, > and there are quite highly optimized functions for dealing with NOV > lines. Yes... but if nnmaildir-retrieve-headers returns 'headers instead of 'nov, won't Gnus just scan through that data and construct NOV lines before any other processing? IOW, it's no benefit to return NOV lines unless I can do a better job of caching them than Gnus does of extracting them, right? > nnimap has code for retrieving header data from the IMAP server and > then caching this data in NOV format on the local disk. Maybe that > kind of approach would work for you, too? The first time you enter a= > group, you gather NOV lines for all messages, and on subsequent visit= s > you just read that cache file. Yeah, that'd work, but keeping that information in a separate file means that expiring a message will be more work than just deleting a single file. So far, I've been able to get away with not keeping any centralized state, in memory or on disk. I'd like to avoid biting that bullet, if possible. > > The server argument to the backend functions is the second element > > of the select method, right? >=20 > I don't think so. It just identifies a server. There are two ways t= o > identify a server. One way is to use a string, which is treated like= > a name and then looked up in the list of all servers. The other > possibility is to have a complete server definition, along the lines > of (nnml "frumple" (nnml-get-new-mail nil)), ie with server parameter= s > and all. According to my experiments, the second element of a select method *is* the `server' argument passed to the backed functions. The third element is the optional `defs' argument passed to *-open-server. This is typically relayed to nnoo-change-server, which picks up all those name-value pairs and makes them real. AFAICT. > Hmmm... I have written a backend which seems to work, and I still > don't know what that server argument really means. It appears that > nnoo is your friend, because it means you don't have to know all the > gory details. Sure, but who's your friend when you *want* to know those details? :) > > A string, typically? And as the author of the backend, I decide > > what it means? (Right now, I'm using it to specify the path to the= > > maildir, but I think I'll create a backend variable for that purpos= e > > instead.) >=20 > Well, you could assign to it some meaning. But I think it would be > better to just treat it as a name. This way, users can decide what > their group names look like. Ok. I'll do that. > > Can I see a concrete example of what a real-life NOV line would loo= k > > like, as written to nntp-server-buffer? >=20 > Lessee: >=20 > 1=09Username/password for submission of ECDL paper=09Kai.Grossjohann@= CS.Uni-Dortmund.DE (Kai Gro=DFjohann)=0928 Apr 2000 16:17:50 +0200=09=09=09160=097=09Xref: lucy.cs.un= i-dortmund.de conf.y2000.ecdl:1=09To: ecdl2000@bn.pt=09 >=20 > These are tab-separated fields. So what happens when there's a tab in the subject? > I'm not sure about the two numbers 160 and 7. Chars and lines, preceded by references, empty in this case. > Then comes the Xref header (I'm not sure what that means), In NNTP, it contains the server name (without the domain, according to RFC 1036, contrary to your example and others I've found) and `newsgroup:article number' tuples. > But this format is surely described somewhere in the Gnus info file? Sort of. The info doesn't say whether, e.g., I should write the subject line verbatim, or if I should make it read-able as a Lisp string. > > Can I get away with using article numbers for references there? >=20 > Gnus identifies messages by their numbers. But can it construct threads via article numbers directly, or does it assume that references will be Message-IDs, as is the case with NNTP? > > How does Gnus know whether a backend supports article identificatio= n > > by article number ranges or Message-IDs? I guess backends must fai= l > > sensibly if they don't support these, hm? >=20 > I think Gnus will barf if the backend doesn't support article numbers= . Yes, but *ranges* (((1 . 4)) instead of (1 2 3 4)) are not universally supported by backends, I think. I'm using gnus-member-of-range now, though, so I don't have to worry about that one. paul