making gnus-summary-reparent-thread work right with nnml

making gnus-summary-reparent-thread work right with nnml

[Steinar Bang]

Platform: Emacs 19.34, gnus-5.4.67 with nnml backend, SPARC, Solaris 2.5

I've never gotten gnus-summary-reparent-thread to work right.  If I
insert a References: header or edit an existing References: header
manually with gnus-summary-edit-article, it is immediately rethreaded
when I do a C-c C-c.

If I use gnus-summary-reparent-thread, I don't see the new References:
header when I toggle all headers with the "t" command, if the message
had no References: header to begin with (this is the part I don't know
how to make work).  Also "Fetch parent" doesn't work for these
articles. 

If the article already has a References header, the new article number
is inserted at the start (looking at the code at the end of this
message), and I belive it should be inserted at the end...? (at least
that's the way I understand 2.2.5 of RFC 1036...)  One way to make
this work, would be to strip away the earlier contents of the
References: header, before inserting the message-id of the new parent.

Anyways, if someone could come up with ideas of how to fix this for an
emacs lisp semi literate, I would be thankful (I'm tired of hand
editing Eudora, Outlook and MSExchange messages).

Thanx!


- Steinar

code from lisp/gnus-sum.el:
...
(defun gnus-summary-reparent-thread ()
  "Make the current article child of the marked (or previous) article.

Note that the re-threading will only work if `gnus-thread-ignore-subject'
is non-nil or the Subject: of both articles are the same."
  (interactive)
  (unless (not (gnus-group-read-only-p))
    (error "The current newsgroup does not support article editing"))
  (unless (<= (length gnus-newsgroup-processable) 1)
    (error "No more than one article may be marked"))
  (save-window-excursion
    (let ((gnus-article-buffer " *reparent*")
	  (current-article (gnus-summary-article-number))
	  ;; First grab the marked article, otherwise one line up.
	  (parent-article (if (not (null gnus-newsgroup-processable))
			      (car gnus-newsgroup-processable)
			    (save-excursion
			      (if (eq (forward-line -1) 0)
				  (gnus-summary-article-number)
				(error "Beginning of summary buffer"))))))
      (unless (not (eq current-article parent-article))
	(error "An article may not be self-referential"))
      (let ((message-id (mail-header-id
			 (gnus-summary-article-header parent-article))))
	(unless (and message-id (not (equal message-id "")))
	  (error "No message-id in desired parent"))
	(gnus-summary-select-article t t nil current-article)
	(set-buffer gnus-original-article-buffer)
	(let ((buf (format "%s" (buffer-string))))
	  (nnheader-temp-write nil
	    (insert buf)
	    (goto-char (point-min))
	    (if (search-forward-regexp "^References: " nil t)
		(insert message-id " " )
	      (insert "References: " message-id "\n"))
	    (unless (gnus-request-replace-article
		     current-article (car gnus-article-current)
		     (current-buffer))
	      (error "Couldn't replace article"))))
	(set-buffer gnus-summary-buffer)
	(gnus-summary-unmark-all-processable)
	(gnus-summary-rethread-current)
	(gnus-message 3 "Article %d is now the child of article %d"
		      current-article parent-article)))))
...

Re: making gnus-summary-reparent-thread work right with nnml

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

> Platform: Emacs 19.34, gnus-5.4.67 with nnml backend, SPARC, Solaris 2.5

And tm 7.105, I forgot to add.

> I've never gotten gnus-summary-reparent-thread to work right.  If I
> insert a References: header or edit an existing References: header
> manually with gnus-summary-edit-article, it is immediately rethreaded
> when I do a C-c C-c.

> If I use gnus-summary-reparent-thread, I don't see the new References:
> header when I toggle all headers with the "t" command, if the message
> had no References: header to begin with (this is the part I don't know
> how to make work).  Also "Fetch parent" doesn't work for these
> articles. 

I thought that tm might be the culprit here, so I first tried toggling
it off without seeing any change in the behaviour.  I then started up
a brand new emacs without tm (I had to load tm's emu-e19.el to be able
to make 5.4.67 run on 19.34, tho... Maybe because it was loaded when
Gnus was byte compiled?), and observed the same behaviour:

The new References field doesn't show up when I toggle all headers
or when I edit the article.  "Fetch parent" reports "No references
in...".

But grep finds a References header in the rethreaded article...

I'm clueless...:-/


- Steinar

automagicly compressed nnml files

[St. Suika Roberts]

I've been using this for a while now, and I haven't lost any mail
since I finished coding it, so I thought I'd mail it in.

It adds one variable, nnmail-article-file-suffix, which is appended to
the nnml-generated filename.  If one has autocompression working, this
will automagicly (de)compress one's mail, if one sets it to ".gz"

Thanks,
	Suika  (I had to diff off of rgnus, so I ended up lopping out
	several other changes.  I hope these patches still work.)
-- 
                      wroberts@tvi.cc.nm.us
Whenever people agree with me I always feel I must be wrong.
                                                                 --Oscar Wilde
   <a href="http://studentweb.tulane.edu/~wrobert2/">Suika no homepage</a>
------------------------------ cut here ------------------------------
--- rgnus/lisp/nnml.el	Mon Aug 25 18:08:22 1997
+++ qgnus/lisp/nnml.el	Tue Oct  7 17:18:54 1997
@@ -342,7 +354,7 @@
     (set-buffer buffer)
     (nnml-possibly-create-directory group)
     (let ((chars (nnmail-insert-lines))
-	  (art (concat (int-to-string article) "\t"))
+	  (art (concat (int-to-string article) nnmail-article-file-suffix "\t"))
 	  headers)
       (when (condition-case ()
 		(progn
@@ -350,7 +362,7 @@
 		   (point-min) (point-max)
 		   (or (nnml-article-to-file article)
 		       (concat nnml-current-directory
-			       (int-to-string article)))
+			       (int-to-string article) nnmail-article-file-suffix))
 		   nil (if (nnheader-be-verbose 5) nil 'nomesg))
 		  t)
 	      (error nil))
@@ -583,7 +600,8 @@
 	(nnml-possibly-create-directory (caar ga))
 	(let ((file (concat (nnmail-group-pathname
 			     (caar ga) nnml-directory)
-			    (int-to-string (cdar ga)))))
+			    (int-to-string (cdar ga))
+			    nnmail-article-file-suffix)))
 	  (if first
 	      ;; It was already saved, so we just make a hard link.
 	      (funcall nnmail-crosspost-link-function first file t)
@@ -627,7 +645,7 @@
     (setcdr active (1+ (cdr active)))
     (while (file-exists-p
 	    (concat (nnmail-group-pathname group nnml-directory)
-		    (int-to-string (cdr active))))
+		    (int-to-string (cdr active)) nnmail-article-file-suffix))
       (setcdr active (1+ (cdr active))))
     (cdr active)))
 
--- rgnus/lisp/nnmail.el	Sat Aug  9 12:46:23 1997
+++ qgnus/lisp/nnmail.el	Wed Oct  8 17:27:15 1997
@@ -180,6 +181,9 @@
   :group 'nnmail-files
   :type 'file)
 
+(defvar nnmail-article-file-suffix nil
+  "suffix to add to single message per file files")
+
 (defcustom nnmail-crash-box "~/.gnus-crash-box"
   "File where Gnus will store mail while processing it."
   :group 'nnmail-files

Re: automagicly compressed nnml files

[Lars Magne Ingebrigtsen]

"St. Suika Roberts" <wroberts@tvi.cc.nm.us> writes:

> It adds one variable, nnmail-article-file-suffix, which is appended to
> the nnml-generated filename.  If one has autocompression working, this
> will automagicly (de)compress one's mail, if one sets it to ".gz"

This is already in Gnus.  If you require `jka-compr', nnml will snarf
gzipped articles files.

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

Re: automagicly compressed nnml files

[Simon Josefsson]

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

> > It adds one variable, nnmail-article-file-suffix, which is appended to
> > the nnml-generated filename.  If one has autocompression working, this
> > will automagicly (de)compress one's mail, if one sets it to ".gz"
> 
> This is already in Gnus.  If you require `jka-compr', nnml will snarf
> gzipped articles files.

Does this work with nnfolders too?  Couldn't get it to work
anyway. (yes, i've toggled toggle-auto-compression)

I started adding gzip-support for nnfolders some days ago but ran into
a minor problem -- if the nnfolder file didn't exist it is created (as
0b file) somewhere before nnfolder-read-folder get invoked so I
couldn't just replace the call to nnheader-find-file-noselect with a
function that gzip-d's the nnfolder file and then read it as it where
an ordinary nnfolder if it couldn't find the nnfolder-file. (*)

Basically I want to gzip some of my nnfolders and then automagically
have Gnus try to gzip -d <nnfolder>.gz if <nnfolder> doesn't exist,
and on group-close gzip the folder again.

(*): Sorry if this is a Bad way to implement it, I don't know Gnus and
I probably can't program Elisp.

Re: automagicly compressed nnml files

[Simon Josefsson]

Simon Josefsson <jas@pdc.kth.se> writes:

> Does this work with nnfolders too?  Couldn't get it to work
> anyway.

Thanks to St. Suika Roberts I got it to work.

(If anyone else is interested: If I renamed the Gnus-folder to
<folder>.gz Gnus tries to open it which will start jka-compr which
will unzip it)

Re: automagicly compressed nnml files

[David Hedbor]

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

> "St. Suika Roberts" <wroberts@tvi.cc.nm.us> writes:
> 
> > It adds one variable, nnmail-article-file-suffix, which is appended to
> > the nnml-generated filename.  If one has autocompression working, this
> > will automagicly (de)compress one's mail, if one sets it to ".gz"
> 
> This is already in Gnus.  If you require `jka-compr', nnml will snarf
> gzipped articles files.

The whole point with this patch is that the files are _saved_ gzipped
per default. Loading jka-compr makes it possible to load mail files
gzipped with an external program. Not the same thing.

I can add that this patch is very useful and nice. I never have to
bother doing manual gzipping anymore. 


-- 
[ Below is a random fortune, which is unrelated to the above message. ]
BASIC is to computer programming as QWERTY is to typing.
		-- Seymour Papert

Re: automagicly compressed nnml files

[Lars Magne Ingebrigtsen]

David Hedbor <david@hedbor.org> writes:

> The whole point with this patch is that the files are _saved_ gzipped
> per default. Loading jka-compr makes it possible to load mail files
> gzipped with an external program. Not the same thing.

No, but it also did the same thing that we already have support for.
A patch for providing just automatic gzipping would be nice.

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

Re: automagicly compressed nnml files

[David Hedbor]

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

> David Hedbor <david@hedbor.org> writes:
> 
> > The whole point with this patch is that the files are _saved_ gzipped
> > per default. Loading jka-compr makes it possible to load mail files
> > gzipped with an external program. Not the same thing.
> 
> No, but it also did the same thing that we already have support for.
> A patch for providing just automatic gzipping would be nice.

Ok, I didn't look that much in the patch. I agree that it's redundant
with double support for that. It's just the saving-methods that needs
to be changed.

Oh, btw, is there a way to change "B m" and "B r" to use "mv" instead
of loading, removing and saving the article?

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Every program has (at least) two purposes:
	the one for which it was written and another for which it wasn't.

Re: automagicly compressed nnml files

[Lars Magne Ingebrigtsen]

David Hedbor <david@hedbor.org> writes:

> Oh, btw, is there a way to change "B m" and "B r" to use "mv" instead
> of loading, removing and saving the article?

Nope.  It has to do it that way to work in the general case.

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

Re: automagicly compressed nnml files

[David Hedbor]

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

> David Hedbor <david@hedbor.org> writes:
> 
> > Oh, btw, is there a way to change "B m" and "B r" to use "mv" instead
> > of loading, removing and saving the article?
> 
> Nope.  It has to do it that way to work in the general case.

I am aware of that, but as I only use nnml, on a local disk, it would
be nice to be able to configure the behavior. Would it be very hard to 
make it configurable?

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Reisner's Rule of Conceptual Inertia:
	If you think big enough, you'll never have to do it.

Re: automagicly compressed nnml files

[Lars Magne Ingebrigtsen]

David Hedbor <david@hedbor.org> writes:

> > > Oh, btw, is there a way to change "B m" and "B r" to use "mv" instead
> > > of loading, removing and saving the article?
> > 
> > Nope.  It has to do it that way to work in the general case.
> 
> I am aware of that, but as I only use nnml, on a local disk, it would
> be nice to be able to configure the behavior. Would it be very hard to 
> make it configurable?

Yes.

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

Re: making gnus-summary-reparent-thread work right with nnml

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> If the article already has a References header, the new article number
> is inserted at the start (looking at the code at the end of this
> message), and I belive it should be inserted at the end...? (at least
> that's the way I understand 2.2.5 of RFC 1036...)

Yup.  Fix in Quassia Gnus v0.14.

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

Re: making gnus-summary-reparent-thread work right with nnml

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> If the article already has a References header, the new article number
>> is inserted at the start (looking at the code at the end of this
>> message), and I belive it should be inserted at the end...? (at least
>> that's the way I understand 2.2.5 of RFC 1036...)

> Yup.  Fix in Quassia Gnus v0.14.

I haven't tried using reparenting on articles with an existing, bogus
References header (eg. Eudora Pro 3.x), but I've noted that qgnus 0.14
immediately correctly rethreads articles without a previous references
header.

But! There's still no References header when you toggle on all headers
after reparenting.  And "Fetch parent of article" still reports no
"References in article...".

I see now, when I enter that group from gnus 5.5.67, that the article
reparented in qgnus now has a References header.  Maybe exiting and
entering the group fixed it?  Hmm... still not silk-smooth, tho'...


- Steinar