(Missed) threaded mail entries

(Missed) threaded mail entries

[Stephen Zander]

I've been trying to track this down, but finally decided to see if some else
has already done so...

Reading mail with the nnmh back-end, and gather-by-references I get several
messages left out of the thread tree.  I've checked the headers and the
troublesome messages generally have 'In-Replay-To' set in the same my
current post does (ie, the way MH likes to make them).

My first guess was that the \n between the "your message of..." and the "<>"
reference was screwing things up but tracing gnus-get-newsgroup-headers
in gnus-sum.el has convinced me otherwise.

Before I decend further to the depths, has anyone come across this, fixed it, 
got any suggestions?  I probably should examine the header vector more
closely but haven't :/

This is Gnus 5.4.52 but it also occurs under xemacs20.3 (which isn't in front
of me so I do't remember the Gnus version numer.)

Stephen
---
"Normality is a statistical illusion." -- me

Re: (Missed) threaded mail entries

[Kai Grossjohann]

>>>>> On Tue, 16 Dec 1997, Stephen Zander said:

  Stephen> Reading mail with the nnmh back-end, and
  Stephen> gather-by-references I get several messages left out of the
  Stephen> thread tree.  I've checked the headers and the troublesome
  Stephen> messages generally have 'In-Replay-To' set in the same my
  Stephen> current post does (ie, the way MH likes to make them).

Is the subject of the non-threaded part different from the subject of
the threaded part?

If so, try setting gnus-thread-ignore-subject to t.

Just a stab in the dark,
kai
-- 
Kai Grossjohann, Informatik VI        grossjohann@ls6.cs.uni-dortmund.de
Uni Dortmund, D-44221 Dortmund        http://ls6-www.cs.uni-dortmund.de/
                                      Vox +49 231 755 5670, Fax -2405
I like both kinds of music.

Re: (Missed) threaded mail entries

[Stephen Zander]

Kai Grossjohann wrote:
> Is the subject of the non-threaded part different from the subject of
> the threaded part?

Doesn't appear to be.

> If so, try setting gnus-thread-ignore-subject to t.

However, this did improve things (once I patched gnus-sum.el to treat
References & In-Rply-To the same :)).  I'll continue to look at this
while I'm getting a better understanding of mail expiry :>

Stephen
---
"Normality is a statistical illusion." -- me

Re: (Missed) threaded mail entries

[Stephen Zander]

Lars Magne Ingebrigtsen wrote:
> This doesn't really help much.  If the header was 
> 
>    In-reply-to: Message <87oh2lclzm.fsf@pfaffben.user.msu.edu>
>      from Ben Pfaff <pfaffben@pilot.msu.edu>
> 
> instead, Gnus would do the right thing now, and the wrong thing with
> your patch.

I'm aware of that.  They patch was only meant for my local use and only
designed to fix my specific problem.  The only generic solution I can see
would be to maintain a list of all reference-like entries in In-Reply-To
and special case the processing of that list - which comes under the heading
of Too-Much-For-Right-Now :)

I only posted it 'cause I was asked :)

Stephen
---
"Normality is a statistical illusion." -- me

Re: (Missed) threaded mail entries

[Lars Magne Ingebrigtsen]

Stephen Zander <srz@mckesson.com> writes:

> Sure, here you go.  This patch just makes 'gnus-get-newsgroup-headers' use
> the same rules regardless of the field being a References or an In-Reply-To.
> Specifically, this fixes a problem with mailers that use In-Reply-To lines
> like the following:
> 
>   In-reply-to: Message from Ben Pfaff <pfaffben@pilot.msu.edu>
>     of 13 Dec 1997 10:15:57 EST. <87oh2lclzm.fsf@pfaffben.user.msu.edu> 

[...]

> -	      (if (search-forward "\nreferences: " nil t)
> +	      ;; Get the references from the in-reply-to header if there
> +	      ;; were no references and the in-reply-to header looks
> +	      ;; promising.
> +	      (if (or (search-forward "\nreferences: " nil t)
> +		      (search-forward "\nin-reply-to: " nil t))

This doesn't really help much.  If the header was 

   In-reply-to: Message <87oh2lclzm.fsf@pfaffben.user.msu.edu>
     from Ben Pfaff <pfaffben@pilot.msu.edu>

instead, Gnus would do the right thing now, and the wrong thing with
your patch.

In-Reply-To is a header that contains unstructured text.  There is no
way to parse it in a way that will yield satisfactory results.  

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

Re: (Missed) threaded mail entries

[Stephen Zander]

"Edward J. Sabol" wrote:
> Please post this patch!

Sure, here you go.  This patch just makes 'gnus-get-newsgroup-headers' use
the same rules regardless of the field being a References or an In-Reply-To.
Specifically, this fixes a problem with mailers that use In-Reply-To lines
like the following:

  In-reply-to: Message from Ben Pfaff <pfaffben@pilot.msu.edu>
    of 13 Dec 1997 10:15:57 EST. <87oh2lclzm.fsf@pfaffben.user.msu.edu> 

The current code would incorrectly assume the reference was
<pfaffben@pilot.msu.edu>.

--- gnus-sum.el.orig	Mon Dec 15 23:26:41 1997
+++ gnus-sum.el	Thu Dec 18 13:48:45 1997
@@ -4113,7 +4113,7 @@
       (subst-char-in-region (point-min) (point-max) ?\t ?  t)
       (run-hooks 'gnus-parse-headers-hook)
       (let ((case-fold-search t)
-	    in-reply-to header p lines)
+	    header p lines)
 	(goto-char (point-min))
 	;; Search to the beginning of the next header.	Error messages
 	;; do not begin with 2 or 3.
@@ -4166,7 +4166,11 @@
 	    ;; References.
 	    (progn
 	      (goto-char p)
-	      (if (search-forward "\nreferences: " nil t)
+	      ;; Get the references from the in-reply-to header if there
+	      ;; were no references and the in-reply-to header looks
+	      ;; promising.
+	      (if (or (search-forward "\nreferences: " nil t)
+		      (search-forward "\nin-reply-to: " nil t))
 		  (progn
 		    (setq end (point))
 		    (prog1
@@ -4180,15 +4184,7 @@
 			     (progn
 			       (search-backward "<" end t)
 			       (point))))))
-		;; Get the references from the in-reply-to header if there
-		;; were no references and the in-reply-to header looks
-		;; promising.
-		(if (and (search-forward "\nin-reply-to: " nil t)
-			 (setq in-reply-to (nnheader-header-value))
-			 (string-match "<[^>]+>" in-reply-to))
-		    (setq ref (substring in-reply-to (match-beginning 0)
-					 (match-end 0)))
-		  (setq ref nil))))
+		(setq ref nil)))
 	    ;; Chars.
 	    0
 	    ;; Lines.


Stephen
---
"Normality is a statistical illusion." -- me