* spam-check-BBDB bug?/bbdb whitelist split function @ 2003-02-05 4:15 Bill White 2003-02-05 14:47 ` Ted Zlatanov 0 siblings, 1 reply; 21+ messages in thread From: Bill White @ 2003-02-05 4:15 UTC (permalink / raw) I was futzing around defining my own "if he's in bbdb then he's not spam" split function when I discovered spam-check-BBDB in spam.el: ---------------------------------------------------------------------- (defun spam-check-BBDB () "Mail from people in the BBDB is never considered spam" (let ((who (message-fetch-field "from"))) (when who (setq who (regexp-quote (cadr (gnus-extract-address-components who)))) (if (bbdb-search-simple nil who) nil spam-split-group)))) ---------------------------------------------------------------------- It seems in my tests that bbdb-search-simple does not search for a regexp but for a simple string representation of an address, so I suspect the regexp-quote bit should be removed. I've also adjusted this to return a positive match for bbdb persons; folks who maintain bbdb as a whitelist might find it useful (adjust for local conditions, YMMV, etc.): ---------------------------------------------------------------------- (defun billw-BBDB-whitelist () "BBDB is a whitelist." (let ((who (message-fetch-field "from"))) (when who (setq who (cadr (gnus-extract-address-components who))) (if (bbdb-search-simple nil who) (format-time-string "mail.misc.%Y.%m") nil)))) (setq nnmail-split-fancy '(| ("to" ".*billw@wri\\.com" "spamtrap") ("List-Id" ".*gnucash-announce\\.lists\\.gnucash\\.org.*" "gnucash-announce") ("List-Id" ".*gnucash-user\\.lists\\.gnucash\\.org.*" "gnucash-user") ("List-Id" ".*gnucash-devel\\.lists\\.gnucash\\.org.*" "gnucash-devel") ("List-Id" ".*gnucash-patches\\.lists\\.gnucash\\.org.*" "gnucash-patches") ("List-ID" ".*developer list for mt\\.el.*" "mt-el") ;; [...] ;; my bbdb is a whitelist: save these (: billw-BBDB-whitelist) ;; check for scum (: spam-stat-split-fancy) ;; non-whitelist non-spam: save these (: (lambda nil (format-time-string "mail.misc.%Y.%m"))) )) ---------------------------------------------------------------------- Cheers - bw -- Bill White . billw@wolfram.com . http://members.wri.com/billw "No ma'am, we're musicians." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-check-BBDB bug?/bbdb whitelist split function 2003-02-05 4:15 spam-check-BBDB bug?/bbdb whitelist split function Bill White @ 2003-02-05 14:47 ` Ted Zlatanov 2003-02-05 14:59 ` Bill White 2003-02-05 15:07 ` Niklas Morberg 0 siblings, 2 replies; 21+ messages in thread From: Ted Zlatanov @ 2003-02-05 14:47 UTC (permalink / raw) On Tue, 04 Feb 2003, billw@wolfram.com wrote: > I was futzing around defining my own "if he's in bbdb then he's not > spam" split function when I discovered spam-check-BBDB in spam.el: > > It seems in my tests that bbdb-search-simple does not search for a > regexp but for a simple string representation of an address, so I > suspect the regexp-quote bit should be removed. Thanks, that was left over from the old bbdb-search function call. > I've also adjusted this to return a positive match for bbdb persons; > folks who maintain bbdb as a whitelist might find it useful (adjust > for local conditions, YMMV, etc.): Currently, spam-split will fall through to the next spam/ham check on a whitelist match. I thought of having whitelists return t for a positive ham match, and then spam-split wouldn't examine the rest of the spam/ham checks but simply return nil altogether. Does that makes sense? Or should spam-split have a ham-split-group analogous to spam-split-group? I always assumed people would rather have spam-split fall through on ham than have it be an absolute arbiter, but maybe users would like it the other way. Or both ways. This is Gnus, after all. I'm sure there's a user out there that wants spam-split to retrieve his daily comics :) Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-check-BBDB bug?/bbdb whitelist split function 2003-02-05 14:47 ` Ted Zlatanov @ 2003-02-05 14:59 ` Bill White 2003-02-05 17:57 ` Ted Zlatanov 2003-02-05 15:07 ` Niklas Morberg 1 sibling, 1 reply; 21+ messages in thread From: Bill White @ 2003-02-05 14:59 UTC (permalink / raw) On Wed Feb 05 2003 at 08:47, Ted Zlatanov <tzz@lifelogs.com> said: >> I've also adjusted this to return a positive match for bbdb >> persons; folks who maintain bbdb as a whitelist might find it >> useful (adjust for local conditions, YMMV, etc.): > > Currently, spam-split will fall through to the next spam/ham check > on a whitelist match. > > I thought of having whitelists return t for a positive ham match, > and then spam-split wouldn't examine the rest of the spam/ham checks > but simply return nil altogether. Does that makes sense? Kinda, but I don't have a clear picture of the whole thing (hence my little function to do the one thing I wanted at that precise place). > Or should spam-split have a ham-split-group analogous to > spam-split-group? Aha - that's exactly what I was grepping for last night. > I always assumed people would rather have spam-split fall through on > ham than have it be an absolute arbiter, but maybe users would like > it the other way. Or both ways. This is Gnus, after all. Yes - a user can always whip up some working code that reflects the way he sees reality. > I'm sure there's a user out there that wants spam-split to retrieve > his daily comics :) Now there's an idea... Cheers - bw -- Bill White . billw@wolfram.com . http://members.wri.com/billw "No ma'am, we're musicians." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-check-BBDB bug?/bbdb whitelist split function 2003-02-05 14:59 ` Bill White @ 2003-02-05 17:57 ` Ted Zlatanov 0 siblings, 0 replies; 21+ messages in thread From: Ted Zlatanov @ 2003-02-05 17:57 UTC (permalink / raw) On Wed, 05 Feb 2003, billw@wolfram.com wrote: > On Wed Feb 05 2003 at 08:47, Ted Zlatanov <tzz@lifelogs.com> said: > >>> I've also adjusted this to return a positive match for bbdb >>> persons; folks who maintain bbdb as a whitelist might find it >>> useful (adjust for local conditions, YMMV, etc.): >> >> Currently, spam-split will fall through to the next spam/ham check >> on a whitelist match. >> >> I thought of having whitelists return t for a positive ham match, >> and then spam-split wouldn't examine the rest of the spam/ham >> checks but simply return nil altogether. Does that makes sense? > > Kinda, but I don't have a clear picture of the whole thing (hence my > little function to do the one thing I wanted at that precise place). I had screwed up my code in spam.el - now, spam-use-BBDB and spam-use-whitelist will not go to the next rule, if the sender is in the BBDB/whitelist but simply exit spam-split altogether; also they will only consider messages from people NOT in the BBDB/whitelist spam if spam-use-{whitelist,BBDB}-exclusive is set. Basically, I ended up doing what you (and I assume everyone else) wants out of BBDB/whitelisting, instead of the broken behavior I had in place before. >> Or should spam-split have a ham-split-group analogous to >> spam-split-group? > > Aha - that's exactly what I was grepping for last night. I'd rather have spam-split fall through to the next rule in the split-fancy sequence, I think. It was just not doing the right thing before, that's all... The bug was in the code, not the design. But if people want ham-split-group, I can add it to the ham checks as an option, instead of fall-through. This variable name is getting dangerously close to "split-pea and ham soup." Thanks Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-check-BBDB bug?/bbdb whitelist split function 2003-02-05 14:47 ` Ted Zlatanov 2003-02-05 14:59 ` Bill White @ 2003-02-05 15:07 ` Niklas Morberg 2003-02-05 17:51 ` Ted Zlatanov 1 sibling, 1 reply; 21+ messages in thread From: Niklas Morberg @ 2003-02-05 15:07 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > Currently, spam-split will fall through to the next > spam/ham check on a whitelist match. > > I thought of having whitelists return t for a positive ham > match, and then spam-split wouldn't examine the rest of the > spam/ham checks but simply return nil altogether. Does that > makes sense? Given that I understand you correctly: yes! I get some false positives on mail from people who are in my BBDB when I use spam-stat.el. If what you are writing means: turn on BBDB whitelisting and all mail from everybody in your BBDB will be considered ham, then I am all for it. False positives are really really bad because it means I have to sift through my spam group looking for valid emails. But you knew this already. Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-check-BBDB bug?/bbdb whitelist split function 2003-02-05 15:07 ` Niklas Morberg @ 2003-02-05 17:51 ` Ted Zlatanov 2003-02-10 8:13 ` spam-stat broken? (was: spam-check-BBDB bug?/bbdb whitelist split function) Niklas Morberg 0 siblings, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2003-02-05 17:51 UTC (permalink / raw) On Wed, 05 Feb 2003, niklas.morberg@axis.com wrote: > Ted Zlatanov <tzz@lifelogs.com> writes: > >> Currently, spam-split will fall through to the next >> spam/ham check on a whitelist match. >> >> I thought of having whitelists return t for a positive ham >> match, and then spam-split wouldn't examine the rest of the >> spam/ham checks but simply return nil altogether. Does that >> makes sense? > > Given that I understand you correctly: yes! I get some false > positives on mail from people who are in my BBDB when I use > spam-stat.el. If what you are writing means: turn on BBDB > whitelisting and all mail from everybody in your BBDB will > be considered ham, then I am all for it. Well, here's the embarassing thing: this was how things were supposed to work when Francois Pinard wrote the code, but I didn't pay attention and made whitelist/BBDB checks fall through to the next spam-split rule (they returned nil instead of t). So it's all my fault. > False positives are really really bad because it means I have to > sift through my spam group looking for valid emails. But you knew > this already. I think the new code will fix that, try it (just committed to CVS). I also added spam-use-{whitelist,BBDB}-exclusive for those who want to consider all mail from people NOT in the BBDB/whitelist spam. Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* spam-stat broken? (was: spam-check-BBDB bug?/bbdb whitelist split function) 2003-02-05 17:51 ` Ted Zlatanov @ 2003-02-10 8:13 ` Niklas Morberg 2003-02-11 8:15 ` spam-stat broken? Niklas Morberg 0 siblings, 1 reply; 21+ messages in thread From: Niklas Morberg @ 2003-02-10 8:13 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > I think the new code will fix that, try it (just committed > to CVS). I'm afraid something else broke. Spam-stat hasn't caught a single spam for me lately. I think it stopped working around this time. I tried both to enable and disable the new BBDB related variables. Judging from the message buffer, it does get called -- it's just that the messages are never ever reported as spam. They were before. Snippet from the Messages buffer: Loading c:/cygwin/home/niklas/.spam-stat.el (source)...done spam-split: calling the spam-check-stat function IMAP split moved mailse01.axis.se:INBOX:130822 to incoming Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-stat broken? 2003-02-10 8:13 ` spam-stat broken? (was: spam-check-BBDB bug?/bbdb whitelist split function) Niklas Morberg @ 2003-02-11 8:15 ` Niklas Morberg 2003-02-11 17:56 ` Ted Zlatanov 0 siblings, 1 reply; 21+ messages in thread From: Niklas Morberg @ 2003-02-11 8:15 UTC (permalink / raw) Niklas Morberg <niklas@axis.com> writes: > I'm afraid something else broke. Spam-stat hasn't caught a > single spam for me lately. Sorry, I spoke too soon. It does seem to work, although more spams than previously get through. OTOH I am having problems using the spam functionality with the agent, but I haven't looked at it closely enough to submit a proper problem description. It just feels a bit shaky... There's also the known problem of not being able to automatically move more than one ham message out of the spam group that is a bit annoying. Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-stat broken? 2003-02-11 8:15 ` spam-stat broken? Niklas Morberg @ 2003-02-11 17:56 ` Ted Zlatanov 2003-02-11 20:28 ` Ted Zlatanov 0 siblings, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2003-02-11 17:56 UTC (permalink / raw) On Tue, 11 Feb 2003, niklas.morberg@axis.com wrote: > Niklas Morberg <niklas@axis.com> writes: > >> I'm afraid something else broke. Spam-stat hasn't caught a >> single spam for me lately. > > Sorry, I spoke too soon. It does seem to work, although more > spams than previously get through. I'm not sure how to fix that, but I'd guess your statistics database got skewed somehow. > OTOH I am having problems using the spam functionality with > the agent, but I haven't looked at it closely enough to > submit a proper problem description. It just feels a bit > shaky... I'll follow up in the other thread. > There's also the known problem of not being able to > automatically move more than one ham message out of the > spam group that is a bit annoying. I looked into that, and could not find anything wrong in spam.el's behavior (I'm pretty sure I posted a message to that effect to the ding list, asking for some help). I think the problem was with this code: (dolist (article articles) (when (and (memq (gnus-summary-article-mark article) ham-mark-values) (stringp group)) (let ((gnus-current-article article)) (gnus-summary-move-article nil group)))) in spam-ham-move-routine, but when I ran the routine interactively I could not figure out what was wrong. I'll look at it again, but I can't promise I'll do better this time :) Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-stat broken? 2003-02-11 17:56 ` Ted Zlatanov @ 2003-02-11 20:28 ` Ted Zlatanov 2003-02-12 9:49 ` Niklas Morberg 0 siblings, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2003-02-11 20:28 UTC (permalink / raw) On Tue, 11 Feb 2003, tzz@lifelogs.com wrote: > On Tue, 11 Feb 2003, niklas.morberg@axis.com wrote: >> There's also the known problem of not being able to >> automatically move more than one ham message out of the >> spam group that is a bit annoying. > > I looked into that, and could not find anything wrong in spam.el's > behavior (I'm pretty sure I posted a message to that effect to the > ding list, asking for some help). I think the problem was with this > code: Hm, I think I may have inadvertently fixed the problem :) I'm not sure if it's the right way to do it, but I now set the process-mark on every article that is to be moved, and then call gnus-summary-move-article. It seems to work in my testing. Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-stat broken? 2003-02-11 20:28 ` Ted Zlatanov @ 2003-02-12 9:49 ` Niklas Morberg 2003-02-12 11:16 ` Ted Zlatanov 2003-02-12 13:46 ` Ted Zlatanov 0 siblings, 2 replies; 21+ messages in thread From: Niklas Morberg @ 2003-02-12 9:49 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > Hm, I think I may have inadvertently fixed the problem :) The move routines seem to be working better now, but after some more testing I still see the problem with non-existing messages being displayed in the summary buffer by the agent. > I'm not sure if it's the right way to do it, but I now set the > process-mark on every article that is to be moved, and then call > gnus-summary-move-article. It seems to work in my testing. Is it really necessary to call g-s-m-a for every article? Wouldn't it be more effective to first mark all articles with the process mark and then call g-s-m-a once? Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-stat broken? 2003-02-12 9:49 ` Niklas Morberg @ 2003-02-12 11:16 ` Ted Zlatanov 2003-02-12 13:44 ` Ted Zlatanov 2003-02-12 13:46 ` Ted Zlatanov 1 sibling, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2003-02-12 11:16 UTC (permalink / raw) On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote: > Ted Zlatanov <tzz@lifelogs.com> writes: >> I'm not sure if it's the right way to do it, but I now set the >> process-mark on every article that is to be moved, and then call >> gnus-summary-move-article. It seems to work in my testing. > > Is it really necessary to call g-s-m-a for every article? > Wouldn't it be more effective to first mark all articles > with the process mark and then call g-s-m-a once? As I said, I'm not sure it's the right way. Another issue is, what if you have articles process-marked before you exit a group? Will the process-mark get removed before the spam.el routines get invoked? I didn't test this yesterday because I was in a hurry. Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-stat broken? 2003-02-12 11:16 ` Ted Zlatanov @ 2003-02-12 13:44 ` Ted Zlatanov 0 siblings, 0 replies; 21+ messages in thread From: Ted Zlatanov @ 2003-02-12 13:44 UTC (permalink / raw) On Wed, 12 Feb 2003, tzz@lifelogs.com wrote: > As I said, I'm not sure it's the right way. Another issue is, what > if you have articles process-marked before you exit a group? Will > the process-mark get removed before the spam.el routines get > invoked? I didn't test this yesterday because I was in a hurry. Both issues fixed: - previously process-marked articles are unmarked now before spam/ham articles of interest are process-marked - gnus-summary-move-article is called just once Thanks Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: spam-stat broken? 2003-02-12 9:49 ` Niklas Morberg 2003-02-12 11:16 ` Ted Zlatanov @ 2003-02-12 13:46 ` Ted Zlatanov 2003-02-12 15:00 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg 1 sibling, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2003-02-12 13:46 UTC (permalink / raw) On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote: > Ted Zlatanov <tzz@lifelogs.com> writes: > >> Hm, I think I may have inadvertently fixed the problem :) > > The move routines seem to be working better now, but after > some more testing I still see the problem with non-existing > messages being displayed in the summary buffer by the agent. Can you check now? If there is still a problem, something is wrong in the interaction between the agent and gnus-summary-move-article. Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* The agent shows ghost messages (was: spam-stat broken?) 2003-02-12 13:46 ` Ted Zlatanov @ 2003-02-12 15:00 ` Niklas Morberg 2003-02-12 15:48 ` The agent shows ghost messages Ted Zlatanov 2003-02-12 16:29 ` The agent shows ghost messages (was: spam-stat broken?) Kevin Greiner 0 siblings, 2 replies; 21+ messages in thread From: Niklas Morberg @ 2003-02-12 15:00 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote: >> >> The move routines seem to be working better now, but after >> some more testing I still see the problem with non-existing >> messages being displayed in the summary buffer by the agent. > > Can you check now? If there is still a problem, something > is wrong in the interaction between the agent and > gnus-summary-move-article. There is a problem, but it has nothing to do with the spam functionality. I'm pretty sure the problem is with the agent. Here's a way to repeat it: 1. Start with two unread and undownloaded messages in a group. 2. Read the first message. 3. Move the second message to another group with `B m' without reading it. 4. Exit the group. 5. Re-enter the same group. The second message shows up in the summary buffer, but it not possible to look at it. It has not been downloaded and it is not on the server. This only happens if gnus-agent-mark-unread-after-downloaded is nil. Setting g-a-m-u-a-d to non-nil makes the problem go away. I saw this a lot because I used the spam functionality to do step 3 above and assumed that that was the culprit. Thanks for the other fixes in spam.el, though -- they were certainly not made in vain. I find the spam functionality much more stable now. Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: The agent shows ghost messages 2003-02-12 15:00 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg @ 2003-02-12 15:48 ` Ted Zlatanov 2003-02-12 16:29 ` The agent shows ghost messages (was: spam-stat broken?) Kevin Greiner 1 sibling, 0 replies; 21+ messages in thread From: Ted Zlatanov @ 2003-02-12 15:48 UTC (permalink / raw) On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote: > Thanks for the other fixes in spam.el, though -- they were certainly > not made in vain. I find the spam functionality much more stable > now. Thanks for reporting the bugs, and sorry it took me a while to get back to you. I'm going back to the message registry now :) Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: The agent shows ghost messages (was: spam-stat broken?) 2003-02-12 15:00 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg 2003-02-12 15:48 ` The agent shows ghost messages Ted Zlatanov @ 2003-02-12 16:29 ` Kevin Greiner 2003-02-13 7:53 ` The agent shows ghost messages Niklas Morberg 2003-02-13 8:44 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg 1 sibling, 2 replies; 21+ messages in thread From: Kevin Greiner @ 2003-02-12 16:29 UTC (permalink / raw) Niklas Morberg <niklas.morberg@axis.com> writes: > Ted Zlatanov <tzz@lifelogs.com> writes: > >> On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote: >>> >>> The move routines seem to be working better now, but after >>> some more testing I still see the problem with non-existing >>> messages being displayed in the summary buffer by the agent. >> >> Can you check now? If there is still a problem, something >> is wrong in the interaction between the agent and >> gnus-summary-move-article. > > There is a problem, but it has nothing to do with the spam > functionality. I'm pretty sure the problem is with the agent. Well, I don't use the spam functionality so this is going to be interesting. > Here's a way to repeat it: > > 1. Start with two unread and undownloaded messages in a > group. > > 2. Read the first message. > Niklas, pls do the following command at this point: M-: (debug-on-entry 'gnus-agent-expire) M-: (setq gnus-verbose 7) > 3. Move the second message to another group with `B m' > without reading it. You should have been thrown into the debugger. Did that happen? Was the first argument to gnus-agent-expire a list of one integer; the article # of the article being moved? Type 'c' to continue. Take a look at the message buffer. gnus-agent-expire should have printed messages telling you that it removed the NOV entry for the article in question. Did it? > 4. Exit the group. > > 5. Re-enter the same group. The second message shows up in > the summary buffer, but it not possible to look at it. > It has not been downloaded and it is not on the server. > > This only happens if gnus-agent-mark-unread-after-downloaded > is nil. Setting g-a-m-u-a-d to non-nil makes the problem go > away. You should be using revision 6.142, or later, of gnus-agent.el. Are you? Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: The agent shows ghost messages 2003-02-12 16:29 ` The agent shows ghost messages (was: spam-stat broken?) Kevin Greiner @ 2003-02-13 7:53 ` Niklas Morberg 2003-02-13 8:44 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg 1 sibling, 0 replies; 21+ messages in thread From: Niklas Morberg @ 2003-02-13 7:53 UTC (permalink / raw) Kevin Greiner <kgreiner@xpediantsolutions.com> writes: > Niklas Morberg <niklas.morberg@axis.com> writes: >> >> There is a problem, but it has nothing to do with the >> spam functionality. I'm pretty sure the problem is with >> the agent. > > Well, I don't use the spam functionality so this is going > to be interesting. > >> Here's a way to repeat it: I see that I should have been more clear. What I meant was "Here's a way to repeat it without involving spam functions at all". In other words, following the steps I described should make the problem appear for you as well. I'll respond separately with the information you asked for, Kevin. Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: The agent shows ghost messages (was: spam-stat broken?) 2003-02-12 16:29 ` The agent shows ghost messages (was: spam-stat broken?) Kevin Greiner 2003-02-13 7:53 ` The agent shows ghost messages Niklas Morberg @ 2003-02-13 8:44 ` Niklas Morberg 2003-02-13 13:50 ` The agent shows ghost messages Kevin Greiner 1 sibling, 1 reply; 21+ messages in thread From: Niklas Morberg @ 2003-02-13 8:44 UTC (permalink / raw) Kevin Greiner <kgreiner@xpediantsolutions.com> writes: >> 1. Start with two unread and undownloaded messages in a >> group. >> >> 2. Read the first message. >> > > Niklas, pls do the following command at this point: > M-: (debug-on-entry 'gnus-agent-expire) > M-: (setq gnus-verbose 7) > >> 3. Move the second message to another group with `B m' >> without reading it. > > You should have been thrown into the debugger. Did that happen? Yes. > Was the first argument to gnus-agent-expire a list of one > integer; the article # of the article being moved? Yes. Complete output: * gnus-agent-expire((8673) "incoming" force) gnus-request-move-article(8673 "incoming" "mailse01.axis.se" (gnus-request-accept-article "INBOX" (quote nil) t t) t) gnus-summary-move-article(nil) * call-interactively(gnus-summary-move-article) > Type 'c' to continue. Once again, I end up in the debugger. I hit 'c' again. > Take a look at the message buffer. gnus-agent-expire should have > printed messages telling you that it removed the NOV entry for the > article in question. Did it? No. The contents of the message buffer (after having exited and re-entered the "incoming" group says): Moving to INBOX: (8673)... Loading gnus-dup...done Entering debugger... [2 times] Mark set [2 times] iswitchb-read-buffer: Quit Continuing. Expiring articles in incoming gnus-agent-expire: Loading overview... Done gnus-agent-expire: Sorting entries... Done gnus-agent-expire: Merging entries... Done Expiry...done Entering debugger... [2 times] Mark set [2 times] Continuing. nnimap: Setting marks in INBOX...done nnimap: Updating info for INBOX...done nnimap: Setting marks in incoming...done Retrieving newsgroup: incoming... nnimap: Updating info for incoming...done Fetching headers for incoming...done Generating summary...done No more unread articles >> 4. Exit the group. >> >> 5. Re-enter the same group. The second message shows up in >> the summary buffer, but it not possible to look at it. >> It has not been downloaded and it is not on the server. >> >> This only happens if gnus-agent-mark-unread-after-downloaded >> is nil. Setting g-a-m-u-a-d to non-nil makes the problem go >> away. > > You should be using revision 6.142, or later, of > gnus-agent.el. Are you? Yup: $ cvs status gnus-agent.el =================================================================== File: gnus-agent.el Status: Up-to-date Working revision: 6.142 Repository revision: 6.142 /usr/local/cvsroot/gnus/lisp/gnus-agent.el,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Before doing the steps above I disabled all spam functionality, exited emacs, downloaded a fresh gnus from CVS, built it, installed it and then started emacs. Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: The agent shows ghost messages 2003-02-13 8:44 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg @ 2003-02-13 13:50 ` Kevin Greiner 2003-02-13 14:50 ` Niklas Morberg 0 siblings, 1 reply; 21+ messages in thread From: Kevin Greiner @ 2003-02-13 13:50 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 3476 bytes --] Niklas Morberg <niklas.morberg@axis.com> writes: > Kevin Greiner <kgreiner@xpediantsolutions.com> writes: > >>> 1. Start with two unread and undownloaded messages in a >>> group. >>> >>> 2. Read the first message. >>> >> >> Niklas, pls do the following command at this point: >> M-: (debug-on-entry 'gnus-agent-expire) >> M-: (setq gnus-verbose 7) >> >>> 3. Move the second message to another group with `B m' >>> without reading it. >> >> You should have been thrown into the debugger. Did that happen? > > Yes. > >> Was the first argument to gnus-agent-expire a list of one >> integer; the article # of the article being moved? > > Yes. Complete output: > > * gnus-agent-expire((8673) "incoming" force) > gnus-request-move-article(8673 "incoming" "mailse01.axis.se" (gnus-request-accept-article "INBOX" (quote nil) t t) t) > gnus-summary-move-article(nil) > * call-interactively(gnus-summary-move-article) > >> Type 'c' to continue. > > Once again, I end up in the debugger. I hit 'c' again. > >> Take a look at the message buffer. gnus-agent-expire should have >> printed messages telling you that it removed the NOV entry for the >> article in question. Did it? > > No. The contents of the message buffer (after having exited > and re-entered the "incoming" group says): > > Moving to INBOX: (8673)... > Loading gnus-dup...done > Entering debugger... > [2 times] > Mark set [2 times] > iswitchb-read-buffer: Quit > Continuing. > Expiring articles in incoming > gnus-agent-expire: Loading overview... Done > gnus-agent-expire: Sorting entries... Done > gnus-agent-expire: Merging entries... Done > Expiry...done > Entering debugger... > [2 times] > Mark set [2 times] > Continuing. > nnimap: Setting marks in INBOX...done > nnimap: Updating info for INBOX...done > nnimap: Setting marks in incoming...done > Retrieving newsgroup: incoming... > nnimap: Updating info for incoming...done > Fetching headers for incoming...done > Generating summary...done > No more unread articles > >>> 4. Exit the group. >>> >>> 5. Re-enter the same group. The second message shows up in >>> the summary buffer, but it not possible to look at it. >>> It has not been downloaded and it is not on the server. >>> >>> This only happens if gnus-agent-mark-unread-after-downloaded >>> is nil. Setting g-a-m-u-a-d to non-nil makes the problem go >>> away. >> >> You should be using revision 6.142, or later, of >> gnus-agent.el. Are you? > > Yup: > > $ cvs status gnus-agent.el > =================================================================== > File: gnus-agent.el Status: Up-to-date > > Working revision: 6.142 > Repository revision: 6.142 /usr/local/cvsroot/gnus/lisp/gnus-agent.el,v > Sticky Tag: (none) > Sticky Date: (none) > Sticky Options: (none) > > Before doing the steps above I disabled all spam > functionality, exited emacs, downloaded a fresh gnus from > CVS, built it, installed it and then started emacs. > > Niklas Niklas, The problem is that gnus-agent-expire failed to expire the article. That shouldn't happen when the third parameter is force. It implies that either g-a-e is broken or that 8673 was never fetched into the agent. I've attached a copy of just g-a-e from revision 6.136 as I've been concerned with some recent changes to it. Either append this file to your gnus-agent.el or load it AFTER opening a group. Once you've loaded it, set gnus-verbose to 7 and repeat the 'B m' test. [-- Attachment #2: Old version of gnus-agent-expire --] [-- Type: application/emacs-lisp, Size: 12460 bytes --] [-- Attachment #3: Type: text/plain, Size: 17 bytes --] Thanks, Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: The agent shows ghost messages 2003-02-13 13:50 ` The agent shows ghost messages Kevin Greiner @ 2003-02-13 14:50 ` Niklas Morberg 0 siblings, 0 replies; 21+ messages in thread From: Niklas Morberg @ 2003-02-13 14:50 UTC (permalink / raw) Kevin Greiner <kgreiner@xpediantsolutions.com> writes: > The problem is that gnus-agent-expire failed to expire the > article. That shouldn't happen when the third parameter is > force. It implies that either g-a-e is broken or that 8673 > was never fetched into the agent. Oh. The article wasn't downloaded. I realize I wasn't clear about this in my description. I'm trying to move an undownloaded article because I can tell from its subject alone that I want it in another group. Niklas ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2003-02-13 14:50 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-05 4:15 spam-check-BBDB bug?/bbdb whitelist split function Bill White 2003-02-05 14:47 ` Ted Zlatanov 2003-02-05 14:59 ` Bill White 2003-02-05 17:57 ` Ted Zlatanov 2003-02-05 15:07 ` Niklas Morberg 2003-02-05 17:51 ` Ted Zlatanov 2003-02-10 8:13 ` spam-stat broken? (was: spam-check-BBDB bug?/bbdb whitelist split function) Niklas Morberg 2003-02-11 8:15 ` spam-stat broken? Niklas Morberg 2003-02-11 17:56 ` Ted Zlatanov 2003-02-11 20:28 ` Ted Zlatanov 2003-02-12 9:49 ` Niklas Morberg 2003-02-12 11:16 ` Ted Zlatanov 2003-02-12 13:44 ` Ted Zlatanov 2003-02-12 13:46 ` Ted Zlatanov 2003-02-12 15:00 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg 2003-02-12 15:48 ` The agent shows ghost messages Ted Zlatanov 2003-02-12 16:29 ` The agent shows ghost messages (was: spam-stat broken?) Kevin Greiner 2003-02-13 7:53 ` The agent shows ghost messages Niklas Morberg 2003-02-13 8:44 ` The agent shows ghost messages (was: spam-stat broken?) Niklas Morberg 2003-02-13 13:50 ` The agent shows ghost messages Kevin Greiner 2003-02-13 14:50 ` Niklas Morberg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).