From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/44880 Path: main.gmane.org!not-for-mail From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: funny problems with nnmail-cache and split-fancy-with-parent Date: Mon, 20 May 2002 21:01:54 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87offy9v9p.fsf@alum.wpi.edu> <87vga5xnfc.fsf@alum.wpi.edu> <87n0vh13er.fsf@alum.wpi.edu> <87r8ko822k.fsf@alum.wpi.edu> <87661sqgsc.fsf@alum.wpi.edu> <87661pcwbo.fsf@alum.wpi.edu> <87g00t9vjg.fsf@alum.wpi.edu> <87u1p2vrn1.fsf@alum.wpi.edu> <873cwmvfan.fsf@alum.wpi.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1021921383 14060 127.0.0.1 (20 May 2002 19:03:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 20 May 2002 19:03:03 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 179sQw-0003ef-00 for ; Mon, 20 May 2002 21:03:02 +0200 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 179sQh-0003TV-00; Mon, 20 May 2002 14:02:47 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 20 May 2002 14:03:05 -0500 (CDT) 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 OAA05063 for ; Mon, 20 May 2002 14:02:51 -0500 (CDT) Original-Received: (qmail 4342 invoked by alias); 20 May 2002 19:02:27 -0000 Original-Received: (qmail 4337 invoked from network); 20 May 2002 19:02:27 -0000 Original-Received: from waldorf.cs.uni-dortmund.de (129.217.4.42) by gnus.org with SMTP; 20 May 2002 19:02:27 -0000 Original-Received: from lothlorien.cs.uni-dortmund.de (lothlorien [129.217.19.67]) by waldorf.cs.uni-dortmund.de with ESMTP id g4KJ20b05661 for ; Mon, 20 May 2002 21:02:00 +0200 (MES) Original-Received: from lucy.cs.uni-dortmund.de (lucy [129.217.19.80]) by lothlorien.cs.uni-dortmund.de id VAA04874; Mon, 20 May 2002 21:01:54 +0200 (MET DST) Original-Received: by lucy.cs.uni-dortmund.de (Postfix, from userid 6104) id 92FCC3B41D; Mon, 20 May 2002 21:01:54 +0200 (CEST) Original-To: ding@gnus.org In-Reply-To: <873cwmvfan.fsf@alum.wpi.edu> (Josh Huber's message of "Mon, 20 May 2002 14:34:56 -0400") Original-Lines: 95 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.50 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:44880 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:44880 Josh Huber writes: > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Gro=DFjohann) writes: > >> I'm using nnimap (mainly) and nnml (for just a few messages). >> .nnmail-cache looks okay wrt the group names: most messages don't >> mention a group, and some of them mention "inbox" or "spam". Seems >> fine, since these are the two nnml groups I use at the moment. > > Should I assume you're not using splitting in Gnus to split the IMAP > articles? (is this even possible?) I don't know what you should do :-) But seriously, I use nnmail-split-methods for the nnml mails, whereas I use server-side splitting (our Cyrus server supports Sieve) for nnimap. (Note that Gnus supports splitting for nnimap, too. See the variable nnimap-split-rule=B9.) >> But a sizable number of lines have ^M at the end. Hm. >> Anything special I should look for? > > That's pretty odd...are these lines with no group listed? Is there a > \t after the msgid on those lines? I'm not really seeing how that > could happen, unless the group name was somehow "^M" by accident... Maybe my wording was unclear. By ^M I mean character number 13, aka CR. I don't mean the two characters ^ and M. I think ascii 13 is not allowed in group names. The ^M is at EOL. So this smells of a DOSish file. But of course I have no idea where these characters come from. Here is a typical ^M inflicted line: =0D Hm. Now that I look at the file it seems that most message ids are from me. Strange. And all the ^M lines seem to come from messages I sent from an nnimap group. (I have magic in my .gnus file to put a token in the msg id so that I can file followups in the same group as their originals.) >> Another things that's been on my mind for a while is that it might >> be useful to change the .nnmail-cache format to include the server >> with the group name. It is in principle easy to do, but I don't >> know how to do it in a backward-compatible manner. Suggestions? > > Doing this in a backward-compatible way is going to be hard, I agree. > Since nnmail-cache-fetch-group does this: > > (when (search-backward id nil t) > (beginning-of-line) > (skip-chars-forward "^\n\r\t") > (unless (eolp) > (forward-char 1) > (buffer-substring (point) > (progn (end-of-line) (point))))) > > It's difficult to get it to work...the first thing that comes to mind > is to add a second line including more information which will never > get matched as a messageid: > > examplemsgid29sdf13499@foo.bar.com mail.lists.foo > *** ((group . "mail.lists.foo") (server . (nnml ""))) Hm? I think you're looking in the wrong place for the problems. I think it's entirely sufficient to put group names such as nnml+private:foo.bar into the file. The only problem is that the natural interpretation for `bare' group names is that they come from the primary (native) server. But this is clearly not the case for the old group names. One possibility would be to use the magic string `native' for the primary server. Then bare group names could be interpreted as relative to the primary mail backend (as defined by the current code). And all other group names are fully qualified. Another possibility would be to define a third field. Lines with only one field are old lines without group name. Lines with two fields are old lines with group name. Lines with three fields include the server, where an empty third field could mean the native server. Otherwise the third field could have a form such as nnml:foo (like shown in the server buffer). Maybe it would be useful for Gnus to define a certain standard as to what server names should look like. I'm a bit confused. Sometimes, it's nnml:foo, sometimes it's just foo. People tried to explain to me before, but I still don't understand. Must be a thickhead ;-) Does this rant make any sense at all? I think I need some rest... kai --=20 Silence is foo!