From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/66529 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: drafts and expiry-target problem and solution Date: Wed, 19 Mar 2008 14:33:10 +0900 Organization: Emacsen advocacy group Message-ID: References: <87r6eevweh.fsf@pascal.matem.unam.mx> <87abkv4kxm.fsf@aphrodite.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1205904885 22170 80.91.229.12 (19 Mar 2008 05:34:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2008 05:34:45 +0000 (UTC) Cc: ding@gnus.org To: nils-dated-1213237429.39274f@ackermath.info Original-X-From: ding-owner+M15016@lists.math.uh.edu Wed Mar 19 06:35:14 2008 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.50) id 1JbqxE-0008Ht-Mw for ding-account@gmane.org; Wed, 19 Mar 2008 06:35:13 +0100 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 1Jbqw8-00044d-Jz; Wed, 19 Mar 2008 00:34:04 -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 1Jbqw5-00044R-If for ding@lists.math.uh.edu; Wed, 19 Mar 2008 00:34:01 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.67) (envelope-from ) id 1Jbqvz-0001MK-Ap for ding@lists.math.uh.edu; Wed, 19 Mar 2008 00:34:01 -0500 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Jbqw6-0005qk-00 for ; Wed, 19 Mar 2008 06:34:02 +0100 Original-Received: from [66.225.201.151] (port=48462 helo=mail.jpl.org) by orlando.hostforweb.net with esmtpa (Exim 4.68) (envelope-from ) id 1JbqvN-0006JW-Uc; Wed, 19 Mar 2008 00:33:18 -0500 X-Hashcash: 1:20:080319:nils-dated-1213237429.39274f@ackermath.info::VuWyfhdBGgOBQh1r:0000000000000000003Y2Q X-Hashcash: 1:20:080319:ding@gnus.org::jDz4Fu1TO3c3juZs:0000A7Rp X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:nNAVrcZBwyI0hrKADNtINKYjL7Q= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - gnus.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:66529 Archived-At: --=-=-= >>>>> Nils Ackermann wrote: > On second thought it appears to me that `message-disassociate-draft' > shouldn't rely on `nnmh-request-expire-articles' to delete the mail > from the drafts group. It should just delete it. Is there any deep > reason for this choice? I agree that `message-disassociate-draft' always deletes a draft backup since it differs from a normal message, i.e., it has a header separator, etc. But `nndraft-request-expire-articles', that uses `nnmh-request-expire-articles', is easy to use because it knows what draft to be deleted, I think. A corner-cutting way is: --=-=-= Content-Type: text/x-patch Content-Disposition: inline --- nnmh.el~ 2008-03-18 22:47:32 +0000 +++ nnmh.el 2008-03-19 05:29:22 +0000 @@ -257,8 +257,10 @@ (nnmh-possibly-change-directory newsgroup server) (let ((is-old t) (nnmail-expiry-target - (or (gnus-group-find-parameter newsgroup 'expiry-target t) - nnmail-expiry-target)) + (if (string-equal newsgroup "nndraft:drafts") + 'delete + (or (gnus-group-find-parameter newsgroup 'expiry-target t) + nnmail-expiry-target))) article rest mod-time) (nnheader-init-server-buffer) --=-=-= Content-Disposition: inline >>> A quick grep through source (by parameter names) showed that there are >>> many places where (general) group parameters aren't honored, even if >>> they should be. Potentially this gives rise to a lot of bugs that >>> seem unrelated. Probably there are also more places where the full >>> group specification is missing in using `gnus-group-find-parameter'. > This seems much more serious to me. I am considering helping to > rectify this. Please instruct me about signing the papers. Thanks. I sent a recipe to you. --=-=-=--