A T does not work in nnimap

A T does not work in nnimap

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]


And I can't figure out why.

I don't know if our nnimap guru is aware of it, so I prefer to have it
been said twice than none. :-)

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> And I can't figure out why.

`A T' refuses to work if the backend doesn't support NOV headers?  I'm
not sure why, though.  Could just be a performance consideration.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Thu, Oct 07 2010, Lars Magne Ingebrigtsen wrote:

> `A T' refuses to work if the backend doesn't support NOV headers?  I'm
> not sure why, though.  Could just be a performance consideration.

Yes, that's it. I've been digging into the code, but I barely know
anything about NOV. The old nnimap -retrieve-header function used to do
almost the same thing that the current one is doing, but returned 'nov
instead of 'headers.

Something should be done in this area I guess.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Something should be done in this area I guess.

I think it is that way because 'nov is so much faster than headers,
historically.  But if the user taps `A T', then the user taps `A T'.  I
think the restriction should just go away.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Tue, Oct 12 2010, Lars Magne Ingebrigtsen wrote:

> I think it is that way because 'nov is so much faster than headers,
> historically.  But if the user taps `A T', then the user taps `A T'.  I
> think the restriction should just go away.

I've tried to remove it by simply removing the checks in the code, but
that's not enough unfortunately. :-(

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:

    Julien> On Tue, Oct 12 2010, Lars Magne Ingebrigtsen wrote:
    >> I think it is that way because 'nov is so much faster than
    >> headers, historically.  But if the user taps `A T', then the user
    >> taps `A T'.  I think the restriction should just go away.

    Julien> I've tried to remove it by simply removing the checks in the
    Julien> code, but that's not enough unfortunately. :-(

I started looking at this over the weekend but real work intervened. As
I understand it gnus-summary-refer-thread just downloads lots of headers
and tries to pull the thread out of them. For nnimap its much easier
(and faster) to use search to find the relevant articles; that's what I
did for nnir. It should be pretty trivial to copy the nnir--goto-thread
logic to gnus-summary-refer-thread (unless I have grossly misunderstood
what this function does, which is quite possible).

I'll do it if I get a chance (maybe later today).

Best
Andy

Re: A T does not work in nnimap

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

OK here is a first pass at modifying gnus-summary-refer-thread to work
with imap. It seemed like a good idea to factor out a thread-searching
function for nnimap, so I did. 

Only lightly tested.

Regards,
Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: imap threading changes --]
[-- Type: text/x-diff, Size: 5102 bytes --]

diff --git a/lisp/nnir.el b/lisp/nnir.el
index 2a264d1..2dcebe6 100644
--- a/lisp/nnir.el
+++ b/lisp/nnir.el
@@ -343,7 +343,8 @@
 (eval-when-compile
   (autoload 'nnimap-buffer "nnimap")
   (autoload 'nnimap-command "nnimap")
-  (autoload 'nnimap-possibly-change-group "nnimap"))
+  (autoload 'nnimap-possibly-change-group "nnimap")
+  (autoload 'nnimap-find-thread "nnimap"))
 
 (nnoo-declare nnir)
 (nnoo-define-basics nnir)
@@ -717,21 +718,8 @@ and show thread that contains this article."
 	 (refs (split-string
 		(mail-header-references (gnus-summary-article-header)))))
     (if (string= (car (gnus-group-method group)) "nnimap")
-	(with-current-buffer (nnimap-buffer)
-	  (let* ((cmd (let ((value
-			     (format
-			      "(OR HEADER REFERENCES %s HEADER Message-Id %s)"
-			      id id)))
-			(dolist (refid refs value)
-			  (setq value (format
-				       "(OR (OR HEADER Message-Id %s HEADER REFERENCES %s) %s)"
-				       refid refid value)))))
-		 (result (nnimap-command
-			  "UID SEARCH %s" cmd)))
-	    (gnus-summary-read-group-1 group t t gnus-summary-buffer nil
-				       (and (car result)
-					    (delete 0 (mapcar #'string-to-number
-							      (cdr (assoc "SEARCH" (cdr result)))))))))
+	(gnus-summary-read-group-1 group t t gnus-summary-buffer nil
+				   (nnimap-find-thread id refs))
       (gnus-summary-read-group-1 group t t gnus-summary-buffer
 				 nil (list backend-number))
       (gnus-summary-limit (list backend-number))


diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index c6c8787..5de8518 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1659,6 +1659,22 @@ textual parts.")
 		  group-art))
 	  nnimap-incoming-split-list)))
 
+(defun nnimap-find-thread (id refs)
+  (let* ((cmd (let ((value
+		     (format
+		      "(OR HEADER REFERENCES %s HEADER Message-Id %s)"
+		      id id)))
+		(dolist (refid refs value)
+		  (setq value (format
+			       "(OR (OR HEADER Message-Id %s HEADER REFERENCES %s) %s)"
+			       refid refid value)))))
+	 (result (with-current-buffer (nnimap-buffer)
+		   (nnimap-command
+		    "UID SEARCH %s" cmd))))
+    (and (car result)
+	 (delete 0 (mapcar #'string-to-number
+			   (cdr (assoc "SEARCH" (cdr result))))))))
+
 (provide 'nnimap)
 
 ;;; nnimap.el ends here


diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 1086e28..a2f7a90 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -60,6 +60,7 @@
 (autoload 'gnus-article-outlook-unwrap-lines "deuglify" nil t)
 (autoload 'gnus-article-outlook-repair-attribution "deuglify" nil t)
 (autoload 'gnus-article-outlook-rearrange-citation "deuglify" nil t)
+(autoload 'nnimap-find-thread "nnimap")
 
 (defcustom gnus-kill-summary-on-exit t
   "*If non-nil, kill the summary buffer when you exit from it.
@@ -8828,28 +8829,35 @@ If LIMIT (the numerical prefix), fetch that many old headers instead
 of what's specified by the `gnus-refer-thread-limit' variable."
   (interactive "P")
   (let ((id (mail-header-id (gnus-summary-article-header)))
+	(refs (split-string   (or
+	       (mail-header-references (gnus-summary-article-header)) "")))
 	(limit (if limit (prefix-numeric-value limit)
 		 gnus-refer-thread-limit)))
-    (unless (eq gnus-fetch-old-headers 'invisible)
-      (gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
-      ;; Retrieve the headers and read them in.
-      (if (eq (if (numberp limit)
-		  (gnus-retrieve-headers
-		   (list (min
-			  (+ (mail-header-number
-			      (gnus-summary-article-header))
-			     limit)
-			  gnus-newsgroup-end))
-		   gnus-newsgroup-name (* limit 2))
-		;; gnus-refer-thread-limit is t, i.e. fetch _all_
-		;; headers.
-		(gnus-retrieve-headers (list gnus-newsgroup-end)
-				       gnus-newsgroup-name limit))
-	      'nov)
-	  (gnus-build-all-threads)
-	(error "Can't fetch thread from back ends that don't support NOV"))
-      (gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name))
-    (gnus-summary-limit-include-thread id)))
+    (if (string= (car (gnus-group-method gnus-newsgroup-name)) "nnimap")
+	(progn	(gnus-select-newsgroup gnus-newsgroup-name nil
+				       (nnimap-find-thread id refs))
+		(when gnus-build-sparse-threads
+		  (gnus-build-sparse-threads)))
+      (unless (eq gnus-fetch-old-headers 'invisible)
+	(gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
+	;; Retrieve the headers and read them in.
+	(if (eq (if (numberp limit)
+		    (gnus-retrieve-headers
+		     (list (min
+			    (+ (mail-header-number
+				(gnus-summary-article-header))
+			       limit)
+			    gnus-newsgroup-end))
+		     gnus-newsgroup-name (* limit 2))
+		  ;; gnus-refer-thread-limit is t, i.e. fetch _all_
+		  ;; headers.
+		  (gnus-retrieve-headers (list gnus-newsgroup-end)
+					 gnus-newsgroup-name limit))
+		'nov)
+	    (gnus-build-all-threads)
+	  (error "Can't fetch thread from back ends that don't support NOV"))
+	(gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name)))
+      (gnus-summary-limit-include-thread id)))
 
 (defun gnus-summary-refer-article (message-id)
   "Fetch an article specified by MESSAGE-ID."

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: ChangeLog --]
[-- Type: text/x-diff, Size: 476 bytes --]

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index ab64bcc..c809021 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,12 @@
+2010-10-12  Andrew Cohen  <cohen@andy.bu.edu>
+
+	* nnimap.el (nnimap-find-thread): New function.
+
+	* nnir.el (gnus-summary-nnir-goto-thread): Use it.
+
+	* gnus-sum.el (gnus-summary-refer-thread): Modify to work with
+	imap.
+
 2010-10-12  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* gnus-gravatar.el (gnus-gravatar-too-ugly): Don't test if

Re: A T does not work in nnimap

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

On Wed, Oct 13 2010, Andrew Cohen wrote:

> OK here is a first pass at modifying gnus-summary-refer-thread to work
> with imap. It seemed like a good idea to factor out a thread-searching
> function for nnimap, so I did. 

Looks good. The only problem I see is that when I press A T, I then get
*only* the thread I'm reading. It kicks all the other messages out of
the *Summary* buffer. :-(

> @@ -8828,28 +8829,35 @@ If LIMIT (the numerical prefix), fetch that many old headers instead
>  of what's specified by the `gnus-refer-thread-limit' variable."
>    (interactive "P")
>    (let ((id (mail-header-id (gnus-summary-article-header)))
> +	(refs (split-string   (or
> +	       (mail-header-references (gnus-summary-article-header)) "")))
>  	(limit (if limit (prefix-numeric-value limit)
>  		 gnus-refer-thread-limit)))
> -    (unless (eq gnus-fetch-old-headers 'invisible)
> -      (gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
> -      ;; Retrieve the headers and read them in.
> -      (if (eq (if (numberp limit)
> -		  (gnus-retrieve-headers
> -		   (list (min
> -			  (+ (mail-header-number
> -			      (gnus-summary-article-header))
> -			     limit)
> -			  gnus-newsgroup-end))
> -		   gnus-newsgroup-name (* limit 2))
> -		;; gnus-refer-thread-limit is t, i.e. fetch _all_
> -		;; headers.
> -		(gnus-retrieve-headers (list gnus-newsgroup-end)
> -				       gnus-newsgroup-name limit))
> -	      'nov)
> -	  (gnus-build-all-threads)
> -	(error "Can't fetch thread from back ends that don't support NOV"))
> -      (gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name))
> -    (gnus-summary-limit-include-thread id)))
> +    (if (string= (car (gnus-group-method gnus-newsgroup-name))
> "nnimap")

I'm not sure such a backend check is welcome here. Isn't there a more
generic way to handle that?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:

    Julien> On Wed, Oct 13 2010, Andrew Cohen wrote:
    >> OK here is a first pass at modifying gnus-summary-refer-thread to
    >> work with imap. It seemed like a good idea to factor out a
    >> thread-searching function for nnimap, so I did.

    Julien> Looks good. The only problem I see is that when I press A T,
    Julien> I then get *only* the thread I'm reading. It kicks all the
    Julien> other messages out of the *Summary* buffer. :-(

In fact I'm suspecting that this has uncovered an underlying bug. Just
to make sure its not me, can you go to an nntp group which is displaying
only one message from some multi-message thread in the summary buffer
and try A T?  For me it doesn't incorporate the rest of the thread. 



[...]


    Julien> I'm not sure such a backend check is welcome here. Isn't
    Julien> there a more generic way to handle that?

Well, I should probably do 
(eq (car gnus-find-method-for-group group) 'nnimap)
This seems to be what is used generically for checking the backend
method. I'll make this change.

Thanks,
Andy

Re: A T does not work in nnimap

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

On Wed, Oct 13 2010, Andrew Cohen wrote:

> In fact I'm suspecting that this has uncovered an underlying bug. Just
> to make sure its not me, can you go to an nntp group which is displaying
> only one message from some multi-message thread in the summary buffer
> and try A T?  For me it doesn't incorporate the rest of the thread. 

I'd try but I don't use NNTP at all. :)

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> OK here is a first pass at modifying gnus-summary-refer-thread to work
> with imap. It seemed like a good idea to factor out a thread-searching
> function for nnimap, so I did. 

I think, perhaps, that it would be nice if this worked generally for all
non-NOV backends.  Although the speedup for IMAP is nice, but it should
probably be refactored out into a -request-thread function that would
just return the headers of all the articles that are in the thread.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> OK here is a first pass at modifying gnus-summary-refer-thread to
    >> work with imap. It seemed like a good idea to factor out a
    >> thread-searching function for nnimap, so I did.

    Lars> I think, perhaps, that it would be nice if this worked
    Lars> generally for all non-NOV backends.  Although the speedup for
    Lars> IMAP is nice, but it should probably be refactored out into a
    Lars> -request-thread function that would just return the headers of
    Lars> all the articles that are in the thread.

I definitely agree and started thinking about this while playing around
with A T.

Firstly, this may be beyond my minimal skill set.  But in any case, I
wonder what the backend functions should do. They could return the
headers as you suggest. Or they might just return the list of
articles. But I noticed that there is an imap extension for returning a
threaded list of messages. It might be useful to choose something that
would allow for backend specific speedups in threading.

Since I haven't figured out exactly how threading works at the moment,
I'm not sure whats best.

Regards,
Andy

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Firstly, this may be beyond my minimal skill set.  But in any case, I
> wonder what the backend functions should do. They could return the
> headers as you suggest. Or they might just return the list of
> articles. But I noticed that there is an imap extension for returning a
> threaded list of messages. It might be useful to choose something that
> would allow for backend specific speedups in threading.

Gnus does its own threading according to its own algo.  It's better to
just return a buffer full of article headers and let Gnus do its magic.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> Firstly, this may be beyond my minimal skill set.  But in any
    >> case, I wonder what the backend functions should do. They could
    >> return the headers as you suggest. Or they might just return the
    >> list of articles. But I noticed that there is an imap extension
    >> for returning a threaded list of messages. It might be useful to
    >> choose something that would allow for backend specific speedups
    >> in threading.

    Lars> Gnus does its own threading according to its own algo.  It's
    Lars> better to just return a buffer full of article headers and let
    Lars> Gnus do its magic.

OK. Like I said, probably beyond my skill set, but I'm still trying.

Once I have retrieved the headers (gnus-retrieve-headers), how do I get
them incorporated into the thread? I think I see how to do this with
NOV, but not with the full headers in the nnimap-buffer.

The existing gnus-summary-refer-thread doesn't work very well even for
nntp groups. For example I have one of Julien's messages in this thread
ticked (the only ticked message in gnus.general). If I enter the group
this is the only message showing in the summary buffer. If I then 'A T'
on this message, I get a subset of thread only. From what I can tell the
existing code tries to download a whole bunch of headers and simply
hopes that the full thread is present. Sometimes it is, and sometimes it
isn't. I can guarantee the full thread in nnimap, but only if I do
something special for the nnimap backend, which I think we would like to
avoid. 

Regards,
Andy

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Once I have retrieved the headers (gnus-retrieve-headers), how do I get
> them incorporated into the thread? I think I see how to do this with
> NOV, but not with the full headers in the nnimap-buffer.

You have to parse the headers, and I think `gnus-get-newsgroup-headers'
is probably the right function to do that.  It's what `^' uses, at least.

> I can guarantee the full thread in nnimap, but only if I do something
> special for the nnimap backend, which I think we would like to avoid.

Not necessarily.  We can have a -request-thread function for the
backends that support it (i.e., nnimap), and fall back to just
retrieving a bunch of headers for the other backends.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> Once I have retrieved the headers (gnus-retrieve-headers), how do
    >> I get them incorporated into the thread? I think I see how to do
    >> this with NOV, but not with the full headers in the
    >> nnimap-buffer.

    Lars> You have to parse the headers, and I think
    Lars> gnus-get-newsgroup-headers' is probably the right function to
    Lars> do that.  It's what `^' uses, at least.

That did it. Thanks.

    >> I can guarantee the full thread in nnimap, but only if I do
    >> something special for the nnimap backend, which I think we would
    >> like to avoid.

    Lars> Not necessarily.  We can have a -request-thread function for
    Lars> the backends that support it (i.e., nnimap), and fall back to
    Lars> just retrieving a bunch of headers for the other backends.

OK, so some pseudo-code:

(defun gnus-summary-refer-thread ()
   (if backend-supports-request-thread
       (backend-request-thread)
      (gnus-retrieve-headers bunch))
   (gnus-summary-limit-include-thread id))

Right? I think I might be able to handle this.

Regards,
Andy

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> OK, so some pseudo-code:
>
> (defun gnus-summary-refer-thread ()
>    (if backend-supports-request-thread
>        (backend-request-thread)
>       (gnus-retrieve-headers bunch))
>    (gnus-summary-limit-include-thread id))
>
> Right? I think I might be able to handle this.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Andrew Cohen]

A stupid question (and maybe a bug?)

While trying to include a thread in an imap group with
gnus-summary-limit-include-thread I discovered that sometimes the proper
articles were not getting included. Debugging I found that the
article numbers returned by gnus-articles-in-thread were sometimes
negative (in this case I think it was the article with largest id in the
group, 1038, that was getting reported as -1).

Then I noticed that gnus-newsgroup-limit contained lots of negative
numbers. Is this a bug? Or do negative values have some special meaning?

Regards
Andy

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Then I noticed that gnus-newsgroup-limit contained lots of negative
> numbers. Is this a bug? Or do negative values have some special meaning?

-1 means that the articles either have unknown numbers, or that they
don't have any numbers in the current group at all.  For instance, if
you `^' to an article that was only posted in a different group, you'll
get a -1.  If I remember correctly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> OK, so some pseudo-code: (defun gnus-summary-refer-thread () (if
    >> backend-supports-request-thread (backend-request-thread)
    >> (gnus-retrieve-headers bunch)) (gnus-summary-limit-include-thread
    >> id)) Right? I think I might be able to handle this.

    Lars> Yup.

Here is a version of gnus-summary-refer-thread as discussed, along with
a new nnimap backend function nnimap-request-thread. Only lightly
tested. 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: refer-threads --]
[-- Type: text/x-diff, Size: 3637 bytes --]

diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index b530ce6..2cf4713 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1310,6 +1310,25 @@ textual parts.")
   (setq nnimap-status-string "Read-only server")
   nil)
 
+(deffoo nnimap-request-thread (id refs &optional server)
+  (nnimap-possibly-change-group nil server)
+  (with-current-buffer (nnimap-buffer)
+    (let* ((cmd (let ((value
+		       (format
+			"(OR HEADER REFERENCES %s HEADER Message-Id %s)"
+			id id)))
+		  (dolist (refid refs value)
+		    (setq value (format
+				 "(OR (OR HEADER Message-Id %s HEADER REFERENCES %s) %s)"
+				 refid refid value)))))
+	   (result
+	    (nnimap-command
+	     "UID SEARCH %s" cmd)))
+      (gnus-fetch-headers (and (car result)
+	   (delete 0 (mapcar #'string-to-number
+			     (cdr (assoc "SEARCH" (cdr result))))))))))
+
+
 (defun nnimap-possibly-change-group (group server)
   (let ((open-result t))
     (when (and server


diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 1086e28..dc6a35c 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -8824,31 +8824,41 @@ Return the number of articles fetched."
 
 (defun gnus-summary-refer-thread (&optional limit)
   "Fetch all articles in the current thread.
-If LIMIT (the numerical prefix), fetch that many old headers instead
-of what's specified by the `gnus-refer-thread-limit' variable."
+If no backend-specific 'request-thread function is available
+fetch LIMIT (the numerical prefix) old headers. If LIMIT is nil
+fetch what's specified by the `gnus-refer-thread-limit'
+variable."
   (interactive "P")
   (let ((id (mail-header-id (gnus-summary-article-header)))
+	(refs (split-string
+	       (or (mail-header-references (gnus-summary-article-header))
+		   "")))
 	(limit (if limit (prefix-numeric-value limit)
-		 gnus-refer-thread-limit)))
-    (unless (eq gnus-fetch-old-headers 'invisible)
-      (gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
-      ;; Retrieve the headers and read them in.
-      (if (eq (if (numberp limit)
-		  (gnus-retrieve-headers
-		   (list (min
-			  (+ (mail-header-number
-			      (gnus-summary-article-header))
-			     limit)
-			  gnus-newsgroup-end))
-		   gnus-newsgroup-name (* limit 2))
-		;; gnus-refer-thread-limit is t, i.e. fetch _all_
-		;; headers.
-		(gnus-retrieve-headers (list gnus-newsgroup-end)
-				       gnus-newsgroup-name limit))
-	      'nov)
-	  (gnus-build-all-threads)
-	(error "Can't fetch thread from back ends that don't support NOV"))
-      (gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name))
+		 gnus-refer-thread-limit))
+	(gnus-command-method
+	 (gnus-find-method-for-group gnus-newsgroup-name)))
+    (if  (gnus-check-backend-function 'request-thread gnus-newsgroup-name)
+	(funcall (gnus-get-function gnus-command-method 'request-thread)
+		 id refs)
+      (unless (eq gnus-fetch-old-headers 'invisible)
+	(gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
+	;;	Retrieve the headers and read them in.
+	(if (numberp limit)
+	    (gnus-retrieve-headers
+	     (list (min
+		    (+ (mail-header-number
+			(gnus-summary-article-header))
+		       limit)
+		    gnus-newsgroup-end))
+	     gnus-newsgroup-name (* limit 2))
+	  ;; gnus-refer-thread-limit is t, i.e. fetch _all_
+	  ;; headers.
+	  (gnus-retrieve-headers (list gnus-newsgroup-end)
+				 gnus-newsgroup-name limit)
+	  (gnus-message 5 "Fetching headers for %s...done"
+			gnus-newsgroup-name))))
+    (when (eq gnus-headers-retrieved-by 'nov)
+      (gnus-build-all-threads))
     (gnus-summary-limit-include-thread id)))
 
 (defun gnus-summary-refer-article (message-id)

Re: A T does not work in nnimap

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

Sorry for so many followups, but here is a slightly improved version
(more sensible signature for 'request-thread, and fixed a bug in buffer
handling). 

Let me know if it works.

Regards,
Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: refer-thread changes --]
[-- Type: text/x-diff, Size: 3565 bytes --]

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 1086e28..de3ba50 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -8824,31 +8824,38 @@ Return the number of articles fetched."
 
 (defun gnus-summary-refer-thread (&optional limit)
   "Fetch all articles in the current thread.
-If LIMIT (the numerical prefix), fetch that many old headers instead
-of what's specified by the `gnus-refer-thread-limit' variable."
+If no backend-specific 'request-thread function is available
+fetch LIMIT (the numerical prefix) old headers. If LIMIT is nil
+fetch what's specified by the `gnus-refer-thread-limit'
+variable."
   (interactive "P")
   (let ((id (mail-header-id (gnus-summary-article-header)))
 	(limit (if limit (prefix-numeric-value limit)
-		 gnus-refer-thread-limit)))
-    (unless (eq gnus-fetch-old-headers 'invisible)
-      (gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
-      ;; Retrieve the headers and read them in.
-      (if (eq (if (numberp limit)
-		  (gnus-retrieve-headers
-		   (list (min
-			  (+ (mail-header-number
-			      (gnus-summary-article-header))
-			     limit)
-			  gnus-newsgroup-end))
-		   gnus-newsgroup-name (* limit 2))
-		;; gnus-refer-thread-limit is t, i.e. fetch _all_
-		;; headers.
-		(gnus-retrieve-headers (list gnus-newsgroup-end)
-				       gnus-newsgroup-name limit))
-	      'nov)
-	  (gnus-build-all-threads)
-	(error "Can't fetch thread from back ends that don't support NOV"))
-      (gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name))
+		 gnus-refer-thread-limit))
+	(gnus-command-method
+	 (gnus-find-method-for-group gnus-newsgroup-name)))
+    (if  (gnus-check-backend-function 'request-thread gnus-newsgroup-name)
+	(funcall (gnus-get-function gnus-command-method 'request-thread)
+		 id)
+      (unless (eq gnus-fetch-old-headers 'invisible)
+	(gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
+	;;	Retrieve the headers and read them in.
+	(if (numberp limit)
+	    (gnus-retrieve-headers
+	     (list (min
+		    (+ (mail-header-number
+			(gnus-summary-article-header))
+		       limit)
+		    gnus-newsgroup-end))
+	     gnus-newsgroup-name (* limit 2))
+	  ;; gnus-refer-thread-limit is t, i.e. fetch _all_
+	  ;; headers.
+	  (gnus-retrieve-headers (list gnus-newsgroup-end)
+				 gnus-newsgroup-name limit)
+	  (gnus-message 5 "Fetching headers for %s...done"
+			gnus-newsgroup-name))))
+    (when (eq gnus-headers-retrieved-by 'nov)
+      (gnus-build-all-threads))
     (gnus-summary-limit-include-thread id)))
 
 (defun gnus-summary-refer-article (message-id)


diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 3fbcef6..9b338ff 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1311,6 +1311,25 @@ textual parts.")
   (setq nnimap-status-string "Read-only server")
   nil)
 
+(deffoo nnimap-request-thread (id)
+    (let* ((refs (split-string
+	       (or (mail-header-references (gnus-summary-article-header))
+		   "")))
+	   (cmd (let ((value
+		       (format
+			"(OR HEADER REFERENCES %s HEADER Message-Id %s)"
+			id id)))
+		  (dolist (refid refs value)
+		    (setq value (format
+				 "(OR (OR HEADER Message-Id %s HEADER REFERENCES %s) %s)"
+				 refid refid value)))))
+	   (result
+	    (with-current-buffer (nnimap-buffer)
+	      (nnimap-command  "UID SEARCH %s" cmd))))
+      (gnus-fetch-headers (and (car result)
+	   (delete 0 (mapcar #'string-to-number
+			     (cdr (assoc "SEARCH" (cdr result)))))))))
+
 (defun nnimap-possibly-change-group (group server)
   (let ((open-result t))
     (when (and server

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Sorry for so many followups, but here is a slightly improved version
> (more sensible signature for 'request-thread, and fixed a bug in buffer
> handling). 

Looks good.  The only thing that leaps out is the 

+       (gnus-get-function gnus-command-method 'request-thread)

thing, which is usually done in gnus-int.el, so that you can just call
`gnus-request-thread' directly.  That also takes care of binding
gnus-commmand-method correctly, which is nice for gnus-agent
integration, but it probably makes no matter here...

But make that slight adjustment, and I'll apply it, and we'll see how it
works.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> Sorry for so many followups, but here is a slightly improved
    >> version (more sensible signature for 'request-thread, and fixed a
    >> bug in buffer handling).

    Lars> Looks good.  The only thing that leaps out is the

    Lars> + (gnus-get-function gnus-command-method 'request-thread)

    Lars> thing, which is usually done in gnus-int.el, so that you can
    Lars> just call gnus-request-thread' directly.  That also takes care
    Lars> of binding gnus-commmand-method correctly, which is nice for
    Lars> gnus-agent integration, but it probably makes no matter
    Lars> here...

Cool. Does this work?



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: request-thread --]
[-- Type: text/x-diff, Size: 4121 bytes --]

diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 3fbcef6..9b338ff 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1311,6 +1311,25 @@ textual parts.")
   (setq nnimap-status-string "Read-only server")
   nil)
 
+(deffoo nnimap-request-thread (id)
+    (let* ((refs (split-string
+	       (or (mail-header-references (gnus-summary-article-header))
+		   "")))
+	   (cmd (let ((value
+		       (format
+			"(OR HEADER REFERENCES %s HEADER Message-Id %s)"
+			id id)))
+		  (dolist (refid refs value)
+		    (setq value (format
+				 "(OR (OR HEADER Message-Id %s HEADER REFERENCES %s) %s)"
+				 refid refid value)))))
+	   (result
+	    (with-current-buffer (nnimap-buffer)
+	      (nnimap-command  "UID SEARCH %s" cmd))))
+      (gnus-fetch-headers (and (car result)
+	   (delete 0 (mapcar #'string-to-number
+			     (cdr (assoc "SEARCH" (cdr result)))))))))
+
 (defun nnimap-possibly-change-group (group server)
   (let ((open-result t))
     (when (and server


diff --git a/lisp/gnus-int.el b/lisp/gnus-int.el
index b210df4..19bcffe 100644
--- a/lisp/gnus-int.el
+++ b/lisp/gnus-int.el
@@ -504,6 +504,12 @@ If BUFFER, insert the article in that group."
 	     article (gnus-group-real-name group)
 	     (nth 1 gnus-command-method) buffer)))
 
+(defun gnus-request-thread (id)
+  "Request the thread containing the article specified by Message-ID id."
+  (let ((gnus-command-method (gnus-find-method-for-group gnus-newsgroup-name)))
+    (funcall (gnus-get-function gnus-command-method 'request-thread)
+	     id)))
+
 (defun gnus-request-head (article group)
   "Request the head of ARTICLE in GROUP."
   (let* ((gnus-command-method (gnus-find-method-for-group group))


diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 1086e28..568e297 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -8824,31 +8824,35 @@ Return the number of articles fetched."
 
 (defun gnus-summary-refer-thread (&optional limit)
   "Fetch all articles in the current thread.
-If LIMIT (the numerical prefix), fetch that many old headers instead
-of what's specified by the `gnus-refer-thread-limit' variable."
+If no backend-specific 'request-thread function is available
+fetch LIMIT (the numerical prefix) old headers. If LIMIT is nil
+fetch what's specified by the `gnus-refer-thread-limit'
+variable."
   (interactive "P")
   (let ((id (mail-header-id (gnus-summary-article-header)))
 	(limit (if limit (prefix-numeric-value limit)
 		 gnus-refer-thread-limit)))
-    (unless (eq gnus-fetch-old-headers 'invisible)
-      (gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
-      ;; Retrieve the headers and read them in.
-      (if (eq (if (numberp limit)
-		  (gnus-retrieve-headers
-		   (list (min
-			  (+ (mail-header-number
-			      (gnus-summary-article-header))
-			     limit)
-			  gnus-newsgroup-end))
-		   gnus-newsgroup-name (* limit 2))
-		;; gnus-refer-thread-limit is t, i.e. fetch _all_
-		;; headers.
-		(gnus-retrieve-headers (list gnus-newsgroup-end)
-				       gnus-newsgroup-name limit))
-	      'nov)
-	  (gnus-build-all-threads)
-	(error "Can't fetch thread from back ends that don't support NOV"))
-      (gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name))
+    (if  (gnus-check-backend-function 'request-thread gnus-newsgroup-name)
+	(gnus-request-thread id)
+      (unless (eq gnus-fetch-old-headers 'invisible)
+	(gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
+	;;	Retrieve the headers and read them in.
+	(if (numberp limit)
+	    (gnus-retrieve-headers
+	     (list (min
+		    (+ (mail-header-number
+			(gnus-summary-article-header))
+		       limit)
+		    gnus-newsgroup-end))
+	     gnus-newsgroup-name (* limit 2))
+	  ;; gnus-refer-thread-limit is t, i.e. fetch _all_
+	  ;; headers.
+	  (gnus-retrieve-headers (list gnus-newsgroup-end)
+				 gnus-newsgroup-name limit)
+	  (gnus-message 5 "Fetching headers for %s...done"
+			gnus-newsgroup-name))))
+    (when (eq gnus-headers-retrieved-by 'nov)
+      (gnus-build-all-threads))
     (gnus-summary-limit-include-thread id)))
 
 (defun gnus-summary-refer-article (message-id)

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Cool. Does this work?

Thanks; applied.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Julien Danjou]

On Thu, Oct 14 2010, Andrew Cohen wrote:

> Cool. Does this work?

It works nice but has 1 bug.

When I select a message, I press A T and the full thread is displayed,
including that message *again*. So it get displayed twice in the
*Summary* and in the thread hierarchy.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:

    Julien> On Thu, Oct 14 2010, Andrew Cohen wrote:
    >> Cool. Does this work?

    Julien> It works nice but has 1 bug.

    Julien> When I select a message, I press A T and the full thread is
    Julien> displayed, including that message *again*. So it get
    Julien> displayed twice in the *Summary* and in the thread
    Julien> hierarchy.

Thats interesting. So you see two summary lines for the same article?
I'm not seeing this.


(I'm assuming this is in an imap group). The function simply gets the
headers for the messages in the thread and then calls
gnus-summary-limit-include-thread which I haven't touched (yet). Can you
edebug through this and see whats happening?

Regards,
Andy

Re: A T does not work in nnimap

[Julien Danjou]

On Fri, Oct 15 2010, Andrew Cohen wrote:

> Thats interesting. So you see two summary lines for the same article?
> I'm not seeing this.

Yes.

> (I'm assuming this is in an imap group). The function simply gets the
> headers for the messages in the thread and then calls
> gnus-summary-limit-include-thread which I haven't touched (yet). Can you
> edebug through this and see whats happening?

This is an IMAP. I'll give it a try. :)

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: A T does not work in nnimap

[Steinar Bang]

>>>>> Julien Danjou <julien@danjou.info>:

> On Fri, Oct 15 2010, Andrew Cohen wrote:
>> Thats interesting. So you see two summary lines for the same article?
>> I'm not seeing this.

> Yes.

Are any of you running with nnimap+agent?

I've seen some strangenesses here (in some cases i get NOV file content
in what should be the cached article, in one case on one of my gnusen I
see the same article in two articles (this one persists even when I've
gone off agent.  The articles are different on the server, and on other
gnus clients.  .newsrc.eld messup...?)).

Re: A T does not work in nnimap

[Julien Danjou]

On Fri, Oct 15 2010, Steinar Bang wrote:

> Are any of you running with nnimap+agent?

Oh, damn not!

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:

    Julien> On Fri, Oct 15 2010, Andrew Cohen wrote:
    >> Thats interesting. So you see two summary lines for the same
    >> article?  I'm not seeing this.

    Julien> Yes.

What is the value of gnus-summary-ignore-duplicate-messages?

Re: A T does not work in nnimap

[Julien Danjou]

On Fri, Oct 15 2010, Andrew Cohen wrote:

>>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:
> What is the value of gnus-summary-ignore-duplicate-messages?

If you mean gnus-summary-ignore-duplicates, it's nil, the default value.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: A T does not work in nnimap

[Andrew Cohen]

Looking at the code its common to override the default for
gnus-summary-ignore-duplicates when building threads so I'll just do
that. Patch shortly. 

Whats the rationale for the default value of nil?

Re: A T does not work in nnimap

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 67 bytes --]

In any case here is a patch. Let me know if it fixes the problem.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: drop duplicates in summary thread --]
[-- Type: text/x-diff, Size: 489 bytes --]

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 568e297..c50d8aa 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -8830,6 +8830,7 @@ fetch what's specified by the `gnus-refer-thread-limit'
 variable."
   (interactive "P")
   (let ((id (mail-header-id (gnus-summary-article-header)))
+	(gnus-summary-ignore-duplicates t)
 	(limit (if limit (prefix-numeric-value limit)
 		 gnus-refer-thread-limit)))
     (if  (gnus-check-backend-function 'request-thread gnus-newsgroup-name)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: changes --]
[-- Type: text/x-diff, Size: 396 bytes --]

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index b82aabc..f7b9ef5 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2010-10-15  Andrew Cohen  <cohen@andy.bu.edu>
+
+	* gnus-sum.el (gnus-summary-refer-thread): unconditionally ignore
+	duplicates. 
+
 2010-10-14  Lars Magne Ingebrigtsen  <larsi@gnus.org>
 
 	* nnimap.el (nnimap-open-connection): Message when opening connection

Re: A T does not work in nnimap

[Julien Danjou]

On Fri, Oct 15 2010, Andrew Cohen wrote:

> In any case here is a patch. Let me know if it fixes the problem.

It fixes it, I've pushed that patch.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: A T does not work in nnimap

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 201 bytes --]

Umm, apparently you have to DO something with headers once you've
retrieved them :)

This is a small bug fix which solves my problem that 'A T' would
sometimes fail to show the thread.

Regards,
Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnus-sum fix --]
[-- Type: text/x-diff, Size: 661 bytes --]

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index c50d8aa..39f6314 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -8834,7 +8834,11 @@ variable."
 	(limit (if limit (prefix-numeric-value limit)
 		 gnus-refer-thread-limit)))
     (if  (gnus-check-backend-function 'request-thread gnus-newsgroup-name)
-	(gnus-request-thread id)
+	(setq gnus-newsgroup-headers
+	      (gnus-merge 'list
+			  gnus-newsgroup-headers
+			  (gnus-request-thread id)
+			  'gnus-article-sort-by-number))
       (unless (eq gnus-fetch-old-headers 'invisible)
 	(gnus-message 5 "Fetching headers for %s..." gnus-newsgroup-name)
 	;;	Retrieve the headers and read them in.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: changes --]
[-- Type: text/x-diff, Size: 407 bytes --]

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 1a66ec9..35a9de4 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2010-10-16  Andrew Cohen  <cohen@andy.bu.edu>
+
+	* gnus-sum.el (gnus-summary-refer-thread): Bug fix. Add the thread
+	headers to gnus-newsgroup-headers.
+
 2010-10-15  Andrew Cohen  <cohen@andy.bu.edu>
 
 	* gnus-sum.el (gnus-summary-refer-thread): unconditionally ignore

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> This is a small bug fix which solves my problem that 'A T' would
> sometimes fail to show the thread.

Thanks; applied.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Whats the rationale for the default value of nil?

In some groups you may get messages that have the same Message-ID but
are different articles.  Like nndraft groups and stuff.  Probably.  I
think. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: A T does not work in nnimap

[Andrew Cohen]

>>>>> "Andrew" == Andrew Cohen <cohen@andy.bu.edu> writes:

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:
    Julien> On Fri, Oct 15 2010, Andrew Cohen wrote:
    >>> Thats interesting. So you see two summary lines for the same
    >>> article?  I'm not seeing this.


    Andrew> What is the value of gnus-summary-ignore-duplicate-messages?

And this is the culprit. I have this set to t but if I set it to nil I
see the duplicate entry in the summary buffer.

I can work around this but AFAICT from the code this is the expected
behavior. I don't want to go overriding it in that case.

From gnus-dependencies-add-header:

"If `gnus-summary-ignore-duplicates' is nil then duplicate Message-IDs
will not be entered in the DEPENDENCIES table.  Otherwise duplicate
Message-IDs will be renamed to a unique Message-ID before being
entered."

Re: A T does not work in nnimap

[Julien Danjou]

On Fri, Oct 15 2010, Andrew Cohen wrote:

> I can work around this but AFAICT from the code this is the expected
> behavior. I don't want to go overriding it in that case.
>
> From gnus-dependencies-add-header:
>
> "If `gnus-summary-ignore-duplicates' is nil then duplicate Message-IDs
> will not be entered in the DEPENDENCIES table.  Otherwise duplicate
> Message-IDs will be renamed to a unique Message-ID before being
> entered."

What about a little (let ((gnus-summary-ignore-duplicates t))) ?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info