From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57046 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Configuring spam.el: A few questions Date: Fri, 16 Apr 2004 10:36:10 -0400 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4noeps9ehx.fsf@b2-25-3.bwh.harvard.edu> References: <4nvfkkvodw.fsf@lifelogs.com> <4n7jwhaug6.fsf@b2-25-3.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082126137 11477 80.91.224.253 (16 Apr 2004 14:35:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Apr 2004 14:35:37 +0000 (UTC) Original-X-From: ding-owner+M5586@lists.math.uh.edu Fri Apr 16 16:35:26 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEURB-00026v-00 for ; Fri, 16 Apr 2004 16:35:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BEUQS-0003lJ-00; Fri, 16 Apr 2004 09:34:41 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BEUQO-0003lE-00 for ding@lists.math.uh.edu; Fri, 16 Apr 2004 09:34:36 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BEUQN-00076L-C4 for ding@lists.math.uh.edu; Fri, 16 Apr 2004 09:34:35 -0500 Original-Received: from clifford.bwh.harvard.edu (clifford.bwh.harvard.edu [134.174.9.41]) by justine.libertine.org (Postfix) with ESMTP id 558343A0026 for ; Fri, 16 Apr 2004 09:34:33 -0500 (CDT) Original-Received: from b2-25-3.bwh.harvard.edu (b2-25-3 [134.174.54.60]) by clifford.bwh.harvard.edu (8.10.2+Sun/8.11.0) with ESMTP id i3GEYQ114284 for ; Fri, 16 Apr 2004 10:34:26 -0400 (EDT) Original-To: ding@gnus.org 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: ding@gnus.org In-Reply-To: (Jonas Steverud's message of "Fri, 16 Apr 2004 11:42:25 +0200") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (usg-unix-v) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57046 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57046 On Fri, 16 Apr 2004, tvrud@bredband.net wrote: > I see. One reason for my confusion where the line "This is the > gnus-registry.el package, works with other backends besides > nnmail.", which I interpret as "the registry does not work with > nnmail." I later realises what the "besides" nnmail means in this > context. My fault, sorry. I'll fix that in the comments for the next CVS commit. > I found a ... bug or flaw, depending on how you see it, in > nnmail-split-fancy-with-parent. If I copy one of you emails to > another group, e.g. nnfolder:ToDo, responses end up in the ToDo > group instead of in the Ding group. In one sense, this is correct > behavior but how do I make it not happen for copied mails? Not that > it is a big issue, I'm just curious. For nnmail-split-fancy-with-parent, you should ask the people that maintain that code, it's not me. With copies there's no 100% correct behavior, there's a clear case to be made that the newer copy should get priority as well. gnus-registry returns the first group it finds, which is no more correct than any other approach IMO. We could have a list of regexes that match "preferred groups" though if that seems better. > If I've understood it correctly, nnmail is the mail handling > interface, the front end "Gnus" sees and then it uses a number of > backends like nnfolder to actually store and handle the > emails. Right? I.e. nnmail is not a backend that can replace > nnfolder et all. Think in OOP terms - nnmail is like a parent object that has common functionality for many backends, but by itself it's not a full implementation. >> "Unseen" are those articles you never saw before. >> >> "Unread" are those that are not marked read, expired, ticked, etc. > > This could be added to the Terminology node in the info file (which > I just found) (and which could do with some M-x sort-lines ;-) > ). IMHO. If you submit a patch to show what you mean, that would be very helpful. Thanks Ted