From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45844 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: nnmaildir oddities! Date: Fri, 26 Jul 2002 22:33:50 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <877kjtm1vl.fsf@mail.paradoxical.net> <87ofd4hqap.fsf@mail.paradoxical.net> <87heiw6fr0.fsf@mail.paradoxical.net> <87vg7c4wrb.fsf@mail.paradoxical.net> <87n0so4vk3.fsf@mail.paradoxical.net> <87vg7c7mlf.fsf@alum.wpi.edu> <87eldzikav.fsf@alum.wpi.edu> <87y9byb6f8.fsf@mail.paradoxical.net> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027715674 32659 127.0.0.1 (26 Jul 2002 20:34:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2002 20:34:34 +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 17YBnE-0008UW-00 for ; Fri, 26 Jul 2002 22:34:32 +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 17YBmx-0003Rz-00; Fri, 26 Jul 2002 15:34:16 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 26 Jul 2002 15:34:40 -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 PAA28996 for ; Fri, 26 Jul 2002 15:34:27 -0500 (CDT) Original-Received: (qmail 21948 invoked by alias); 26 Jul 2002 20:33:52 -0000 Original-Received: (qmail 21943 invoked from network); 26 Jul 2002 20:33:51 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by gnus.org with SMTP; 26 Jul 2002 20:33:51 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6QKXokd000399 for ; Fri, 26 Jul 2002 22:33:50 +0200 Original-To: ding@gnus.org Mail-Copies-To: nobody X-Hashcash: 020726:ding@gnus.org:b223226bd1a46703 In-Reply-To: <87y9byb6f8.fsf@mail.paradoxical.net> (Josh Huber's message of "Fri, 26 Jul 2002 16:06:19 -0400") Original-Lines: 40 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.3.50 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45844 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45844 Josh Huber writes: > Simon Josefsson writes: > >> I didn't follow this thread closely, but respooling in Gnus used >> either nnmail internal stuff or some undocumented backend interface, >> which explains why it doesn't work for nnimap. Maybe the same >> applied to nnmaildir. Documenting the backend interface for >> respooling should be possible though, as well as fixing nnimap.el. >> Anyone? :) > > Well, the problem in nnmaildir was that when you call the respool > function (and eventually call nnmaildir-request-move-article, I > think), it's called with a nil destination group value. In nnml, this > triggers a lookup with your split rules, with nnmaildir this triggers > the backend to save in the current group. (i.e. where it came from) Ah, yes, this was the undocumented backend interface I was talking about. Perhaps it should be mentioned in the manual that a nil group means the backends' split stuff should place the article. What about the following? Maybe nnimap will support it now that it is documented. :-) --- gnus.texi.~6.294.~ 2002-07-26 20:04:47.000000000 +0200 +++ gnus.texi 2002-07-26 22:31:48.000000000 +0200 @@ -23632,6 +23632,9 @@ The function should return a cons where the @code{car} is the group name and the @code{cdr} is the article number that the article was entered as. +If @var{group} is nil, it means the article is respooled and it should +be placed in a group determined by the backends' split rules (if any). + There should be no data returned. > IMHO, the determination of the destination group should happen much > earlier in the game -- doing in buried in each backend is just not the > right thing to do. Split rules are backend specific in Gnus. But I agree, it would be nicer if there was a `gnus-split-rules' that could crosspost across backends too.