From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48340 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Add hooks to Gnus on move/edit/delete? Date: Sun, 29 Dec 2002 22:33:54 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: owner-ding@hpc.uh.edu Message-ID: References: <84fzsgk72x.fsf@lucy.cs.uni-dortmund.de> <847kdswkd6.fsf@lucy.cs.uni-dortmund.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1041219696 4173 80.91.224.249 (30 Dec 2002 03:41:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 30 Dec 2002 03:41:36 +0000 (UTC) Cc: ding@hpc.uh.edu Return-path: Original-Received: from util1.math.uh.edu ([129.7.128.22]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18Sqo2-000153-00 for ; Mon, 30 Dec 2002 04:41:35 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by util1.math.uh.edu with esmtp (Exim 4.10) id 18Sqj0-0003h6-00; Sun, 29 Dec 2002 21:36:22 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 29 Dec 2002 21:35:37 -0600 (CST) Original-Received: from ns1.beld.net (ns1.beld.net [208.229.215.81]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id VAA11489 for ; Sun, 29 Dec 2002 21:35:09 -0600 (CST) Original-Received: from heechee.beld.net (dhcp-0-30-bd-1-93-b2.cpe.beld.net [24.233.65.6]) by ns1.beld.net (Postfix) with ESMTP id 6FB3D3BED3; Sun, 29 Dec 2002 22:33:47 -0500 (EST) Original-To: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann), ?=@ns1.beld.net, ding@hpc.uh.edu In-Reply-To: <847kdswkd6.fsf@lucy.cs.uni-dortmund.de> (kai.grossjohann@uni-duisburg.de's message of "Sun, 29 Dec 2002 23:06:29 +0100") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:48340 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48340 On Sun, 29 Dec 2002, kai.grossjohann@uni-duisburg.de wrote: > I think it might work if you use nnimap splitting. If you use Sieve > or procmail, then it could be difficult, since the ifile database > would be on your local host in the home dir, whereas the > Sieve/procmail rules are on the IMAP server. We can explicitly require that in the manual. >> So if ifile-spam-filter could and should be replaced with another >> ifile-gnus.el function that returns regular group names, spam.el >> can do all the ifile classification automatically if the user just >> sets spam-use-ifile to t. >> >> Does that sound reasonable? > > I'm not sure. How do I tell spam.el which group a message is in? > If ifile has chosen the group wrongly, how do I tell it about the > error? I think it's supposed to be automatic, but currently only bogofilter processing is done: - when entering a spam group ( a member of spam-junk-mailgroups), all unread messages are marked as spam - when exiting any group: - spam-marked articles are processed as spam, then marked expired so they are not processed twice and so we don't keep them around. - ham-marked articles are processed as ham (non-spam); these are the gnus-del-mark, gnus-read-mark, gnus-killed-mark, gnus-kill-file-mark, and gnus-low-score-mark articles. There should be, but isn't, a mechanism to prevent them from being processed more than once. Any suggestions? Yet another cache or a supplemental ham-processed-mark? When I say "processed," I mean "passed to bogofilter on the command line with the appropriate flag (-n for ham, -s for spam)." The equivalent of spam-bogofilter-register-routine for ifile needs to be written for ifile processing on group summary exit. I haven't done it yet, because I didn't know that ifile-gnus.el supported nnimap already. So let me know if you think it's ready to be incorporated. > ifile-gnus intercepts move and copy operations to see that. So > designating a message as spam works by moving it to the spam group. With spam.el, you designate a message as spam by marking it with the spam mark. We could automatically move all spam articles in a group to the spam group on summary exit when ifile is enabled, to accomodate its operation mode. But would that be acceptable to users? > Maybe a two-stage process is better: first decide whether it's spam > or not, then distribute the non-spam to the right groups. I'm not sure how that would work. Ted