From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/72079 Path: news.gmane.org!not-for-mail From: Nils Ackermann Newsgroups: gmane.emacs.gnus.general Subject: Re: Any juicy outstanding Gnus bugs? Date: Mon, 27 Sep 2010 23:24:56 -0500 Message-ID: <87vd5qtrzb.fsf@thysbe.fqdn.ackermath.info> References: <877hi9z277.fsf@thysbe.fqdn.ackermath.info> <87y6apxm8x.fsf@thysbe.fqdn.ackermath.info> <87hbhc9x64.fsf@thysbe.fqdn.ackermath.info> <87vd5r5egl.fsf@thysbe.fqdn.ackermath.info> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: dough.gmane.org 1285647957 27396 80.91.229.12 (28 Sep 2010 04:25:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Sep 2010 04:25:57 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M20452@lists.math.uh.edu Tue Sep 28 06:25:56 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P0RlM-0007qx-Fx for ding-account@gmane.org; Tue, 28 Sep 2010 06:25:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1P0Rl4-00086p-Dj; Mon, 27 Sep 2010 23:25:38 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P0Rl0-00086T-Uh for ding@lists.math.uh.edu; Mon, 27 Sep 2010 23:25:34 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1P0Rkw-0000t1-GL for ding@lists.math.uh.edu; Mon, 27 Sep 2010 23:25:34 -0500 Original-Received: from mail.geekisp.com ([216.168.135.169] helo=starfish.geekisp.com) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1P0Rkv-0007Sh-00 for ; Tue, 28 Sep 2010 06:25:29 +0200 Original-Received: (qmail 31475 invoked by uid 1003); 28 Sep 2010 04:24:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ackermath.info; b=ZkEFg2hMg5I/MseDuwYE81cLZd/7/X7QCxqRaZpLinj4P+CIpEtlqwWzGA35fqoFTt4Vw9ClycV3WhldRkOg71biMY0RsITRCIN0rQfj4SW987v2Y7B9DnWqzV0LSFLC ; Original-Received: from dsl-201-124-5-140-dyn.prod-infinitum.com.mx (HELO thysbe.localdomain) (nils@nieback.info@201.124.5.140) by mail.geekisp.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Sep 2010 04:24:58 -0000 Original-Received: by thysbe.localdomain (Postfix, from userid 1000) id 3A79CE5A3E; Mon, 27 Sep 2010 23:24:56 -0500 (CDT) Mail-Copies-To: never In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 27 Sep 2010 20:39:13 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) X-Spam-Score: 1.7 (+) X-Spam-Report: SpamAssassin (3.3.1 2010-03-16) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-1499--2772h-0s--0d--100644, 0.000-848--1567h-0s--0d--H*M:fsf, 0.000-742--1371h-0s--0d--H*u:Emacs, 0.000-730--1349h-0s--0d--H*u:Gnus, 0.000-706--1306h-0s--0d--H*u:linux Spam tokens: 0.993-1--0h-2s--0d--Nils, 0.987-1--0h-1s--0d--H*r:sk:mail.ge, 0.918-190--183h-6075s--0d--composed, 0.870-215--996h-19742s--0d--H*Ad:D*gnus.org, 0.862-167--1180h-21972s--0d--H*RU:quimby.gnus.org Autolearn status: no 2.2 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy [201.124.5.140 listed in combined.njabl.org] 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: ackermath.info] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 T_TVD_MIME_NO_HEADERS BODY: T_TVD_MIME_NO_HEADERS -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:72079 Archived-At: --=-=-= Lars Magne Ingebrigtsen writes: > Nils Ackermann writes: > >>> Digging a bit deeper here, it seemed like it was fetching the expiry >>> target of the wrong group. This may now be fixed. >> >> Nope, sorry. > > Could you edebug through `nndraft-request-expire-articles' and see what > happens? First a typo: --=-=-= Content-Type: text/x-diff Content-Disposition: inline diff --git a/lisp/nndraft.el b/lisp/nndraft.el index 5dc51f3..97ad2b9 100644 --- a/lisp/nndraft.el +++ b/lisp/nndraft.el @@ -224,7 +224,7 @@ are generated if and only if they are also in `message-draft-headers'.") (let* ((nnmh-allow-delete-final t) (nnmail-expiry-target (or (gnus-group-find-parameter - (gnus-group-prefixed-name "nndraft" (list 'nndraft server)) + (gnus-group-prefixed-name "drafts" (list 'nndraft server)) 'expiry-target t) nnmail-expiry-target)) (res (nnoo-parent-function 'nndraft --=-=-= This fixes my setup, hooray! The override of nnmail-expiry-target finally works in the draft group. I wonder though if it wouldn't be better to change this to --=-=-= Content-Type: text/x-diff Content-Disposition: inline diff --git a/lisp/nndraft.el b/lisp/nndraft.el index 5dc51f3..5ad4ed0 100644 --- a/lisp/nndraft.el +++ b/lisp/nndraft.el @@ -222,11 +222,7 @@ are generated if and only if they are also in `message-draft-hea (deffoo nndraft-request-expire-articles (articles group &optional server force) (nndraft-possibly-change-group group) (let* ((nnmh-allow-delete-final t) - (nnmail-expiry-target - (or (gnus-group-find-parameter - (gnus-group-prefixed-name "nndraft" (list 'nndraft server)) - 'expiry-target t) - nnmail-expiry-target)) + (nnmail-expiry-target 'delete) (res (nnoo-parent-function 'nndraft 'nnmh-request-expire-articles (list articles group server force))) --=-=-= If one expires from the drafts group to some other real email folder the aforementioned dreaded ,---- | --text follows this line-- `---- appears in *saved* articles. Wouldn't it be best to ensure that under no circumstances articles are expired to a mail folder from the drafts group? Using expiry from the drafts group to archive sent emails makes no sense anyway since expiry only happens if the composed email is saved at least once during composition. Thanks for looking into this! Cheers, Nils --=-=-=--