[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnus-registry problems

From: Svend Tollak Munkejord
Subject: Re: Gnus-registry problems
Date: Thu, 01 Jul 2004 09:57:37 +0200
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix)

On 2004-06-30, Ted Zlatanov <address@hidden> wrote:

> On Wed, 30 Jun 2004, address@hidden wrote:
>> This time I used "Ibsens ripsbusker" as subject:
>> ozelot:~$ grep -i "ibsens ripsbusker" .gnus.registry.eld
>> ozelot:~$
>> Nothing at all!
> You have to save the registry file ('s' in the group buffer will do
> it, if your newsrc.eld needs to be saved - the registry is saved
> whenever the newsrc.eld is saved).


>> What if I restart Gnus? Ah, then there's something there:
>> ozelot:~$ grep -i "ibsens ripsbusker" .gnus.registry.eld
>> ("<address@hidden>" ((process (ham
>> spam-use-stat "")) (mtime 16610 30770 60011)
>> (subject . "Ibsens ripsbusker")) ""
>> "nnmaildir:mail.misc")
>> ozelot:~$ 
> Excellent.
>>> and then do t M-: (gnus-registry-split-fancy-with-parent) in the
>>> buffer of the article (`t' will show the whole article).  With
>>> gnus-verbose set to 10, I need to know what the Messages buffer
>>> says.
>> OK, I went to the Article buffer of the message with an empty
>> References header and did that. Here's what the Messages buffer
>> said:
>> --8<---------------cut here---------------start------------->8---
>> gnus-registry-split-fancy-with-parent (extra tracking) traced
>> subject Ibsens ri\psbusker to group
>> gnus-registry-split-fancy-with-parent: too many extra matches for
>> nil nil
>> --8<---------------cut here---------------end--------------->8---
>>> There are some reasons why the subject lookup will fail, chiefly
>>> that the same subject may be in various groups (but there are
>>> others, see the function gnus-registry-split-fancy-with-parent).
>>> If there's more than one match for a subject, the lookup is
>>> considered a failure.  I thought about this, and it seems to be
>>> the best way to handle multiple groups.  I'm open to suggestions
>>> if you think otherwise.
>> No, I agree with you. But in this case the Subject was unique. 
> In gnus-registry.el, change line 420-423 to look like this (line to
> be added marked with +):
> (unless (equal res (gnus-registry-fetch-group key))
> (setq single-match nil))
> +(debug single-match subject this-subject res
> +(gnus-registry-fetch-group key))
> (setq res (gnus-registry-fetch-group key))
> Then re-evaluate the gnus-registry-split-fancy-with-parent function,
> and re-run it for the article in question.  


> If you get more than one debug call, the article subject is in
> multiple groups somehow.  If you get just one, there's a bug.

Here's the Backtrace (but I don't know how to use the debugger):

--8<---------------cut here---------------start------------->8---
Debugger entered: ("Ibsens ripsbusker" "Ibsens ripsbusker" nil 
  (progn (unless (equal res ...) (setq single-match nil)) (debug single-match 
subject this-subject res (gnus-registry-fetch-group key)) (setq res 
(gnus-registry-fetch-group key)) (when (and subject res) (gnus-message ... "%s 
(extra tracking) traced subject %s to group %s" 
"gnus-registry-split-fancy-with-parent" subject res)))
  (if (and single-match this-subject (equal subject this-subject)) (progn 
(unless ... ...) (debug single-match subject this-subject res ...) (setq res 
...) (when ... ...)))
  (when (and single-match this-subject (equal subject this-subject)) (unless 
(equal res ...) (setq single-match nil)) (debug single-match subject 
this-subject res (gnus-registry-fetch-group key)) (setq res 
(gnus-registry-fetch-group key)) (when (and subject res) (gnus-message ... "%s 
(extra tracking) traced subject %s to group %s" 
"gnus-registry-split-fancy-with-parent" subject res)))
  (let ((this-subject ...)) (when (and single-match this-subject ...) (unless 
... ...) (debug single-match subject this-subject res ...) (setq res ...) (when 
... ...)))
  (lambda (key value) (let (...) (when ... ... ... ... 
...)))("<address@hidden>" (((process ...) (mtime 16610 30770 60011) (subject . 
"Ibsens ripsbusker")) "" "nnmaildir:mail.misc"))
  maphash((lambda (key value) (let (...) (when ... ... ... ... ...))) 
#<hash-table 'equal nil 15/4096 0x8881b70>)
  (progn (maphash (lambda ... ...) gnus-registry-hashtb))
  (if (and single-match (gnus-registry-track-subject-p) subject (< 
gnus-registry-minimum-subject-length ...)) (progn (maphash ... 
  (when (and single-match (gnus-registry-track-subject-p) subject (< 
gnus-registry-minimum-subject-length ...)) (maphash (lambda ... ...) 
  (let ((sender ...) (subject ...) (single-match t)) (when (and single-match 
... sender) (maphash ... gnus-registry-hashtb)) (when (and single-match ... 
subject ...) (maphash ... gnus-registry-hashtb)) (unless single-match 
(gnus-message 3 "gnus-registry-split-fancy-with-parent: too many extra matches 
for %s" refstr) (setq res nil)))
  (if refstr (progn (setq references ...) (mapcar ... references)) (let (... 
... ...) (when ... ...) (when ... ...) (unless single-match ... ...)))
  (let ((refstr ...) (nnmail-split-fancy-with-parent-ignore-groups ...) 
references res) (if refstr (progn ... ...) (let ... ... ... ...)) (when (and 
refstr res) (gnus-message 5 "gnus-registry-split-fancy-with-parent traced %s to 
group %s" refstr res)) (when (and res gnus-registry-use-long-group-names) (let 
... ...)) res)
  eval-expression((gnus-registry-split-fancy-with-parent) nil)
--8<---------------cut here---------------end--------------->8---

> If you send me your registry file, I may be able to do more
> debugging too.

OK, I'll do that.

>> Another thing: Might it be an idea that the
>> gnus-registry-split-fancy-with-parent function consider the
>> In-Reply-To header if there is no References ?
> We already do that in gnus-registry-split-fancy-with-parent:
> (message-fetch-field "in-reply-to")
> is it not working correctly?

I don't think so. In the e-mail we're discussing, I inserted an empty
References header, and, unfortunately, it didn't get split according
to the Subject. However, Gnus still inserted the In-Reply-To header,
which didn't seem to be used. (Else I guess the e-mail would have been
split correctly/as expected).

Svend Tollak Munkejord 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]