nnimap, expiry-target, nnmail-fancy-expiry-targets

nnimap, expiry-target, nnmail-fancy-expiry-targets

[Davide G. M. Salvetti]

Hi all!

I've a problem with the stuff in the subject line.

I'd like to have all messages of a certain nnimap group (INBOX) auto
archived in a bunch of nnimap groups (on the same IMAP server) named
after year-month, the specific group being chosen based on the date of
the message to be archived.

After reading the docs I thought I could have what I wanted with the
following setup:

  * group parameters:
<======================================================================>
 (total-expire . t)
 (expiry-wait . immediate)
 (expiry-target . nnmail-fancy-expiry-target)
<======================================================================>

  * nnmail-fancy-expiry-targets:
<======================================================================>
(setq nnmail-fancy-expiry-targets
      '(("from" ".*" "nnimap+mail:Mail/Archive/%Y-%m")))
<======================================================================>

(note that here nnimap+mail is a well working backend).

However, it doesn't work as I expected: when I press "C-c C-x" on the
group from the *Group* buffer I get the following backtrace:

<======================================================================>
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match(".*" nil)
  nnmail-fancy-expiry-target("INBOX")
  nnmail-expiry-target-group(nnmail-fancy-expiry-target "INBOX")
  nnimap-expiry-target((1 (3 . 6) (8 . 30) (33 . 75) (77 . 106) (108 . 139) (141 . 152) (155 . 159) (161 . 181) (183 . 235) (237 . 246) (248 . 267) (269 . 270) (272 . 330) (332 . 336) (338 . 339) (341 . 352) (354 . 356) (358 . 363) 365 (367 . 570) (572 . 585) (587 . 594) (596 . 625) (627 . 631) (633 . 639) (641 . 667) (669 . 676) (678 . 696) (698 . 725)) "INBOX" "mail")
  nnimap-request-expire-articles((1 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ...) "INBOX" "mail" nil)
  gnus-request-expire-articles((1 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ...) "nnimap+mail:INBOX")
  gnus-group-expire-articles-1("nnimap+mail:INBOX")
  gnus-group-expire-articles(nil)
  call-interactively(gnus-group-expire-articles)
  gnus-topic-expire-articles(nil)
  call-interactively(gnus-topic-expire-articles)
<======================================================================>

while after (setq imap-log t) *imap-log* shows

<======================================================================>
1730 SELECT "INBOX"
* 722 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1026993069] UID validity status
* OK [UIDNEXT 726] Predicted next UID
* FLAGS (gnus-forward \Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS (gnus-forward \* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags
* OK [UNSEEN 2] first unseen message in /var/mail/salve
1730 OK [READ-WRITE] SELECT completed
1731 EXPUNGE
1731 OK No messages deleted, so no update needed
1732 UID FETCH 1 BODY.PEEK[]
* 1 FETCH (UID 1 BODY[] {4936}
Return-Path: <salve@master.debian.org>

[... an article of that INBOX group elided by yours truly ...]

)
1732 OK UID FETCH completed
1733 UID COPY 1 "Mail/Archive/2002-07"
1733 OK UID COPY completed
1734 EXAMINE "Mail/Archive/2002-07"
* 6 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1027005732] UID validity status
* OK [UIDNEXT 23] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 1] first unseen message in /home/salve/Mail/Archive/2002-07
1734 OK [READ-ONLY] EXAMINE completed
1735 UID FETCH * UID
* 6 FETCH (UID 22)
1735 OK UID FETCH completed
1736 SELECT "INBOX"
* 722 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1026993069] UID validity status
* OK [UIDNEXT 726] Predicted next UID
* FLAGS (gnus-forward \Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS (gnus-forward \* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags
* OK [UNSEEN 2] first unseen message in /var/mail/salve
1736 OK [READ-WRITE] SELECT completed
1737 UID FETCH 3 BODY.PEEK[]
1737 OK UID FETCH completed
<======================================================================>

(note 1737 here above).

I'm afraid I don't know enough of the IMAP protocol to understand it any
further. :-(

Am I doing this thing properly, or is there an other way to reach my
archiving goal?

P.S.  Well, perhaps I should say that I also have a

<======================================================================>
(setq gnus-message-archive-group '((concat "nnimap+mail:Mail/Archive/"
					   (format-time-string
					    "%Y-%m" (current-time)))))
<======================================================================>

which appears to semi-work; i.e., it apparently works as long as I'm not
subscribed to, say, nnimap+mail:Mail/Archive/2002-07, otherwise it fails
to append my outgoing messages there (without barfing: they simply
aren't appended, but I don't get any error message back).

-- 
Salve, | GNU PG (GPG) Key ID: 9396865D
Davide | <http://www.linux.it/~salve/>

Re: nnimap, expiry-target, nnmail-fancy-expiry-targets

[Nevin Kapur]

"Davide G. M. Salvetti" <salve@debian.org> writes:

> I've a problem with the stuff in the subject line.
>

[...]

>   * nnmail-fancy-expiry-targets:
> <======================================================================>
> (setq nnmail-fancy-expiry-targets
>       '(("from" ".*" "nnimap+mail:Mail/Archive/%Y-%m")))
> <======================================================================>
>
> (note that here nnimap+mail is a well working backend).
>
> However, it doesn't work as I expected: when I press "C-c C-x" on the
> group from the *Group* buffer I get the following backtrace:
>
> <======================================================================>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   string-match(".*" nil)
                      ^^^
Bizarre. This implies that one of the articles that you were trying to
expire did not have a From header.  Is that true?

[...]

> 1737 UID FETCH 3 BODY.PEEK[]
> 1737 OK UID FETCH completed
> <======================================================================>
>
> (note 1737 here above).
>
> I'm afraid I don't know enough of the IMAP protocol to understand it any
> further. :-(

Unfortunately, me neither.  When I wrote the fancy expiry stuff, I
relied on message-fetch-field to find the header to match against.

> Am I doing this thing properly, or is there an other way to reach my
> archiving goal?

If it's true that the message in question does not have a From header,
then I guess we should decide on the right behavior.  Certainly an
error is not the right behavior!

If the message does have a from header, could you run

M-: (message-fetch-field "from")

on it and see if you get something non-nil?

-Nevin

Re: nnimap, expiry-target, nnmail-fancy-expiry-targets

[Nevin Kapur]

"Davide G. M. Salvetti" <salve@debian.org> writes:

>
> I've a problem with the stuff in the subject line.
>

[...]

Does the following patch work for you?

Index: lisp/nnmail.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnmail.el,v
retrieving revision 6.46
diff -u -r6.46 nnmail.el
--- lisp/nnmail.el	2002/07/02 16:06:57	6.46
+++ lisp/nnmail.el	2002/07/19 15:49:55
@@ -1770,7 +1770,9 @@
 	(setq target (format-time-string (caddr regexp-target-pair) date)))
        ((and (not (equal header 'to-from))
 	     (string-match (cadr regexp-target-pair)
-			   (message-fetch-field header)))
+			   (or
+			    (message-fetch-field header)
+			    "")))
 	(setq target
 	      (format-time-string (caddr regexp-target-pair) date)))))))
 

nnimap-request-expire-articles bug? (Was Re: nnimap, expiry-target, nnmail-fancy-expiry-targets)

[Davide G. M. Salvetti]

[NB: it seems that messages sent to ding@gnus.org disappear (it happened
thrice to me).  Posting through news.gnus.org appears to work, though.

I've changed the Subject line, due to the fact that I suspect
nnimap-request-expire-articles being the cause of this problem.  More
about it near the end of this message.]

>>>>> "NK" == Nevin Kapur <nevin@jhu.edu> writes:

NK> "Davide G. M. Salvetti" <salve@debian.org> writes:

>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>> string-match(".*" nil)
NK>                  ^^^
NK> Bizarre. This implies that one of the articles that you were trying to
NK> expire did not have a From header.  Is that true?

No, at least AFAIK.

NK> [...]

>> 1737 UID FETCH 3 BODY.PEEK[]
>> 1737 OK UID FETCH completed
>> <======================================================================>
>> 
>> (note 1737 here above).

NK> Unfortunately, me neither.  When I wrote the fancy expiry stuff, I
NK> relied on message-fetch-field to find the header to match against.

What I think is happening here is that the IMAP request #1737 doesn't
get the reply Gnus is expecting.  Gnus expect an article (cfr. IMAP
request #1732 in my <87sn2fiznh.fsf@hal.Olympus.INVALID>), but it gets
nothing at all (I guess if an article was to be sent there, it should
have been sandwiched in the middle of the #1737 request and the #1737
answer).

NK> If it's true that the message in question does not have a From
NK> header,

I think this condition shouldn't happen, as a From field in the header
is necessary indeed (AFAIK, I've not re-checked any RFC).

NK> then I guess we should decide on the right behavior.  Certainly an
NK> error is not the right behavior!

NK> If the message does have a from header, could you run

NK> M-: (message-fetch-field "from")

NK> on it and see if you get something non-nil?

While trying to follow your suggestion, I think I've tracked down the
bug, at least a bit.  Since I needed to know what message corresponded
to UID 3, I browsed the INBOX folder literally, and found that the UID
is recorded in a special X-UID field (on the IMAP server).  Well, the
fact is that no message corresponds to UID 3.

I don't know enough of the IMAP protocol to say if giving a completely
empty message in response to a request for an not existing message is
correct.  Regardless of it, the real question turns out to be: why is
Gnus requesting a non existing message?

So I found that gnus-request-expire-articles is passed a list of
expirable articles which possibly contains no longer existent articles:
since this is a totally-expirable group, it is passed
(gnus-list-of-read-articles group), by gnus-group-expire-articles-1:
according to the source this means active articles minus unread articles
minus dormant articles minus tick marked; the thesis follow since active
articles include deleted articles in between.

When nnimap-request-expire-articles receives this list, it doesn't
subtract non existing articles (contrary to what, say,
nnml-request-expire-articles do), and does the whole list.

Since we have an expiry-target in this group, nnmail-expiry-target-group
gets called in the (possibly empty because no such article exists)
buffer which results from nnimap-request-article, for each (possibly non
existent) article in the list.

In our situation nnmail-expiry-target-group calls
nnmail-fancy-expiry-target, which barfs because it can't find any
"From", "To", "Date", ... in the sadly empty buffer which resulted from
the non existent article request.

I think that nnimap-request-expire-articles should be fixed to subtract
non existing articles before doing the list.  I'd fix it, but at this
moment I don't know how to open the right holes (corresponding to
deleted articles) in the list.

-- 
Salve, | GNU PG (GPG) Key ID: 9396865D
Davide | <http://www.linux.it/~salve/>

[PATCH] nnmail-fancy-expiry-target

[Nevin Kapur]

"Davide G. M. Salvetti" <salve@icube.it> writes:

[...]

> Since we have an expiry-target in this group, nnmail-expiry-target-group
> gets called in the (possibly empty because no such article exists)
> buffer which results from nnimap-request-article, for each (possibly non
> existent) article in the list.

The patch I posted yesterday will work around this by ignoring such
empty buffers and more generally, non-existent headers.

I'm posting it again with a ChangeLog.  Could someone with commit
privileges please apply it?

2002-07-20  Nevin Kapur  <Nevin Kapur <nevin@jhu.edu>

	* nnmail.el (nnmail-fancy-expiry-target): Assume empty header
	  if it doesn't exist.

Index: lisp/nnmail.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnmail.el,v
retrieving revision 6.46
diff -u -r6.46 nnmail.el
--- lisp/nnmail.el	2002/07/02 16:06:57	6.46
+++ lisp/nnmail.el	2002/07/19 15:49:55
@@ -1770,7 +1770,9 @@
 	(setq target (format-time-string (caddr regexp-target-pair) date)))
        ((and (not (equal header 'to-from))
 	     (string-match (cadr regexp-target-pair)
-			   (message-fetch-field header)))
+			   (or
+			    (message-fetch-field header)
+			    "")))
 	(setq target
 	      (format-time-string (caddr regexp-target-pair) date)))))))
 
-Nevin

Re: [PATCH] nnmail-fancy-expiry-target

[Kai Großjohann]

Nevin Kapur <nevin@jhu.edu> writes:

> I'm posting it again with a ChangeLog.  Could someone with commit
> privileges please apply it?

Committed.  The patch is short so it doesn't need paperwork.  But if
you submit more patches, paperwork will be needed...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [PATCH] nnmail-fancy-expiry-target

[Nevin Kapur]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Nevin Kapur <nevin@jhu.edu> writes:
>
>> I'm posting it again with a ChangeLog.  Could someone with commit
>> privileges please apply it?
>
> Committed.  The patch is short so it doesn't need paperwork.  But if
> you submit more patches, paperwork will be needed...

I've already provided the paperwork for Gnus.

-Nevin

Re: [PATCH] nnmail-fancy-expiry-target

[Kai Großjohann]

Nevin Kapur <nevin@jhu.edu> writes:

> I've already provided the paperwork for Gnus.

Thanks.  I can't log in to fencepost at the moment, so I can't check.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [PATCH] nnmail-fancy-expiry-target

[Davide G.M.Salvetti]

[Nevin, I seem to have problems posting to ding.  Will you please check
if this message also shows there, as it should?  Thanks.]

>>>>> "Nevin" == Nevin Kapur <nevin@jhu.edu> writes:

Nevin> The patch I posted yesterday will work around this by ignoring
Nevin> such empty buffers and more generally, non-existent headers.

Ok.  Yet there are two problems still.

1. If the target (nnimap) group where expired articles should go doesn't
   already exists, the articles will be deleted instead (with no error
   signaled to the user).

2. If you have a large hole in the article number sequence (say, you
   have an IMAP group with a three months old ticked article, then a
   large gap of expired articles and then some new articles), the
   expiring process takes for ever.  I guess that's because Gnus request
   a lot of non existing articles from the IMAP server, even if it needs
   not to.

The setup under which these problems showed up here is the same as that
described in my previous articles of this thread (references).

-- 
Salve, | GNU PG (GPG) Key ID: 9396865D
Davide | <http://www.linux.it/~salve/>

Re: [PATCH] nnmail-fancy-expiry-target

[Nevin Kapur]

"Davide G.M.Salvetti" <salve@debian.org> writes:

> [Nevin, I seem to have problems posting to ding.  Will you please check
> if this message also shows there, as it should?  Thanks.]

I am responding to this through ding, so your posting did go through.

>>>>>> "Nevin" == Nevin Kapur <nevin@jhu.edu> writes:
>
> Nevin> The patch I posted yesterday will work around this by ignoring
> Nevin> such empty buffers and more generally, non-existent headers.
>
> Ok.  Yet there are two problems still.
>
> 1. If the target (nnimap) group where expired articles should go doesn't
>    already exists, the articles will be deleted instead (with no error
>    signaled to the user).

This seems to be an nnimap issue - it does not create groups on the
fly.  For nnfolder non-existent groups are created if they don't
exist.

> 2. If you have a large hole in the article number sequence (say, you
>    have an IMAP group with a three months old ticked article, then a
>    large gap of expired articles and then some new articles), the
>    expiring process takes for ever.  I guess that's because Gnus request
>    a lot of non existing articles from the IMAP server, even if it needs
>    not to.

I've seen this too.  I don't know how to fix this.

-Nevin

Re: [PATCH] nnmail-fancy-expiry-target

[Simon Josefsson]

"Davide G.M.Salvetti" <salve@debian.org> writes:

> [Nevin, I seem to have problems posting to ding.  Will you please check
> if this message also shows there, as it should?  Thanks.]
>
>>>>>> "Nevin" == Nevin Kapur <nevin@jhu.edu> writes:
>
> Nevin> The patch I posted yesterday will work around this by ignoring
> Nevin> such empty buffers and more generally, non-existent headers.
>
> Ok.  Yet there are two problems still.
>
> 1. If the target (nnimap) group where expired articles should go doesn't
>    already exists, the articles will be deleted instead (with no error
>    signaled to the user).

Does this patch fix it?

--- nnimap.el.~6.37.~	2002-07-10 18:19:30.000000000 +0200
+++ nnimap.el	2002-07-26 18:42:11.000000000 +0200
@@ -1296,6 +1296,8 @@
 (defun nnimap-expiry-target (arts group server)
   (unless (eq nnmail-expiry-target 'delete)
     (with-temp-buffer
+      (or (imap-mailbox-status group 'UIDVALIDITY)
+	  (imap-mailbox-create group))
       (dolist (art (gnus-uncompress-sequence arts))
 	(nnimap-request-article art group server  (current-buffer))
 	;; hints for optimization in `nnimap-request-accept-article'

> 2. If you have a large hole in the article number sequence (say, you
>    have an IMAP group with a three months old ticked article, then a
>    large gap of expired articles and then some new articles), the
>    expiring process takes for ever.  I guess that's because Gnus request
>    a lot of non existing articles from the IMAP server, even if it needs
>    not to.

Could you profile this to find out what is taking time?  It is
difficult to improve it otherwise.  It may be range calculations that
is taking time, then I'm afraid there may be little to do right now.

Re: [PATCH] nnmail-fancy-expiry-target

[Nevin Kapur]

Simon Josefsson <jas@extundo.com> writes:

> "Davide G.M.Salvetti" <salve@debian.org> writes:

[...]

>> 1. If the target (nnimap) group where expired articles should go doesn't
>>    already exists, the articles will be deleted instead (with no error
>>    signaled to the user).
>
> Does this patch fix it?
>
> --- nnimap.el.~6.37.~	2002-07-10 18:19:30.000000000 +0200
> +++ nnimap.el	2002-07-26 18:42:11.000000000 +0200
> @@ -1296,6 +1296,8 @@
>  (defun nnimap-expiry-target (arts group server)
>    (unless (eq nnmail-expiry-target 'delete)
>      (with-temp-buffer
> +      (or (imap-mailbox-status group 'UIDVALIDITY)
> +	  (imap-mailbox-create group))
>        (dolist (art (gnus-uncompress-sequence arts))
>  	(nnimap-request-article art group server  (current-buffer))
>  	;; hints for optimization in `nnimap-request-accept-article'

Applying this patch gives the following error each time I exit an
nnimap group which does not use delete as its expiry-target:

Signaling: (error "Buffer  *temp* has no process")
  process-send-string(nil "12 STATUS \"mail/Mailbox\" (UIDVALIDITY)\r\n")
  imap-send-command-1("12 STATUS \"mail/Mailbox\" (UIDVALIDITY)")
  imap-send-command(("STATUS \"" "mail/Mailbox" "\" " "(UIDVALIDITY)") nil)
  imap-send-command-wait(("STATUS \"" "mail/Mailbox" "\" " "(UIDVALIDITY)"))
  imap-mailbox-status("mail/Mailbox" UIDVALIDITY)
  nnimap-expiry-target(nil "mail/Mailbox" "jesse")
  nnimap-request-expire-articles((134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 ...) "mail/Mailbox" "jesse" nil)
  gnus-request-expire-articles((134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 ...) "nnimap+jesse:mail/Mailbox")
  gnus-summary-expire-articles()
  run-hooks(gnus-summary-expire-articles)
  apply(run-hooks gnus-summary-expire-articles)
  gnus-run-hooks(gnus-summary-prepare-exit-hook)
  #<compiled-function (&optional temporary) "...(384)" [gname gnus-article-buffer group quit-config buf buffer gnus-set-global-variables gnus-buffer-live-p mm-destroy-parts nil gnus-kill-save-kill-buffer gnus-async-halt-prefetch gnus-group-quit-config gnus-score-adaptive gnus-score-save gnus-run-hooks gnus-summary-prepare-exit-hook get-buffer buffer-name kill-buffer gnus-cache-possibly-remove-articles gnus-cache-save-buffers gnus-async-prefetch-remove-group gnus-dup-enter-articles gnus-tree-close gnus-cache-write-active nnmail-purge-split-history string-match "^[^:]+:" 0 gnus-exit-group-hook gnus-summary-update-info gnus-close-group gnus-group-jump-to-group gnus-summary-exit-hook gnus-group-group-name gnus-group-next-unread-group 1 gnus-deaden-summary gnus-summary-clear-local-variables bury-buffer pop-to-buffer gnus-configure-windows force gnus-handle-ephemeral-exit gnus-summary-mode gnus-newsgroup-name mode group-point gnus-group-buffer ...] 5 ("/usr/local/src/gnus/lisp/gnus-sum.elc" . 173844) nil>()
  call-interactively(gnus-summary-exit)

-Nevin

Re: [PATCH] nnmail-fancy-expiry-target

[Simon Josefsson]

Nevin Kapur <nevin@jhu.edu> writes:

> Applying this patch gives the following error each time I exit an
> nnimap group which does not use delete as its expiry-target:
>
> Signaling: (error "Buffer  *temp* has no process")
>   process-send-string(nil "12 STATUS \"mail/Mailbox\" (UIDVALIDITY)\r\n")

Sorry, try this:

Index: nnimap.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnimap.el,v
retrieving revision 6.37
diff -u -p -u -w -r6.37 nnimap.el
--- nnimap.el	2002/07/10 16:28:39	6.37
+++ nnimap.el	2002/07/29 12:03:00
@@ -1296,6 +1296,8 @@ function is generally only called when G
 (defun nnimap-expiry-target (arts group server)
   (unless (eq nnmail-expiry-target 'delete)
     (with-temp-buffer
+      (or (imap-mailbox-status group 'UIDVALIDITY nnimap-server-buffer)
+	  (imap-mailbox-create group nnimap-server-buffer))
       (dolist (art (gnus-uncompress-sequence arts))
 	(nnimap-request-article art group server  (current-buffer))
 	;; hints for optimization in `nnimap-request-accept-article'

Re: nnimap-request-expire-articles bug? (Was Re: nnimap, expiry-target, nnmail-fancy-expiry-targets)

[Simon Josefsson]

"Davide G. M. Salvetti" <salve@icube.it> writes:

> So I found that gnus-request-expire-articles is passed a list of
> expirable articles which possibly contains no longer existent articles:
> since this is a totally-expirable group, it is passed
> (gnus-list-of-read-articles group), by gnus-group-expire-articles-1:
> according to the source this means active articles minus unread articles
> minus dormant articles minus tick marked; the thesis follow since active
> articles include deleted articles in between.
>
> When nnimap-request-expire-articles receives this list, it doesn't
> subtract non existing articles (contrary to what, say,
> nnml-request-expire-articles do), and does the whole list.
>
> Since we have an expiry-target in this group, nnmail-expiry-target-group
> gets called in the (possibly empty because no such article exists)
> buffer which results from nnimap-request-article, for each (possibly non
> existent) article in the list.
>
> In our situation nnmail-expiry-target-group calls
> nnmail-fancy-expiry-target, which barfs because it can't find any
> "From", "To", "Date", ... in the sadly empty buffer which resulted from
> the non existent article request.
>
> I think that nnimap-request-expire-articles should be fixed to subtract
> non existing articles before doing the list.  I'd fix it, but at this
> moment I don't know how to open the right holes (corresponding to
> deleted articles) in the list.

Yup.  Does this work?

Index: nnimap.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnimap.el,v
retrieving revision 6.37
diff -u -p -u -w -r6.37 nnimap.el
--- nnimap.el	2002/07/10 16:28:39	6.37
+++ nnimap.el	2002/07/29 12:04:54
@@ -1296,7 +1296,10 @@ function is generally only called when G
 (defun nnimap-expiry-target (arts group server)
   (unless (eq nnmail-expiry-target 'delete)
     (with-temp-buffer
-      (dolist (art (gnus-uncompress-sequence arts))
+      (dolist (art (imap-search (concat "UID " 
+					(imap-range-to-message-set
+					 (gnus-uncompress-sequence arts)))
+		    nnimap-server-buffer))
 	(nnimap-request-article art group server  (current-buffer))
 	;; hints for optimization in `nnimap-request-accept-article'
 	(let ((nnimap-current-move-article art)
@@ -1312,16 +1315,15 @@ function is generally only called when G
   (let ((artseq (gnus-compress-sequence articles)))
     (when (and artseq (nnimap-possibly-change-group group server))
       (with-current-buffer nnimap-server-buffer
-	(if force
-	    (progn
-	      (nnimap-expiry-target artseq group server)
-	      (when (imap-message-flags-add (imap-range-to-message-set artseq)
-					    "\\Deleted")
-		(setq articles nil)))
 	  (let ((days (or (and nnmail-expiry-wait-function
 			       (funcall nnmail-expiry-wait-function group))
 			  nnmail-expiry-wait)))
-	    (cond ((eq days 'immediate)
+	    (cond (force
+		   (nnimap-expiry-target artseq group server)
+		   (when (imap-message-flags-add
+			  (imap-range-to-message-set artseq) "\\Deleted")
+		     (setq articles nil)))
+		  ((eq days 'immediate)
 		   (nnimap-expiry-target artseq group server)
 		   (when (imap-message-flags-add
 			  (imap-range-to-message-set artseq) "\\Deleted")

Re: nnimap-request-expire-articles bug? (Was Re: nnimap, expiry-target, nnmail-fancy-expiry-targets)

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> Yup.  Does this work?

Not likely, try this instead.  Still untested, but should at least
evaluate.

Index: nnimap.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnimap.el,v
retrieving revision 6.37
diff -u -p -u -w -r6.37 nnimap.el
--- nnimap.el	2002/07/10 16:28:39	6.37
+++ nnimap.el	2002/07/29 12:14:39
@@ -1296,7 +1296,10 @@ function is generally only called when G
 (defun nnimap-expiry-target (arts group server)
   (unless (eq nnmail-expiry-target 'delete)
     (with-temp-buffer
-      (dolist (art (gnus-uncompress-sequence arts))
+      (dolist (art (imap-search (concat "UID " 
+					(imap-range-to-message-set
+					 (gnus-uncompress-sequence arts)))
+		    nnimap-server-buffer))
 	(nnimap-request-article art group server  (current-buffer))
 	;; hints for optimization in `nnimap-request-accept-article'
 	(let ((nnimap-current-move-article art)
@@ -1312,16 +1315,15 @@ function is generally only called when G
   (let ((artseq (gnus-compress-sequence articles)))
     (when (and artseq (nnimap-possibly-change-group group server))
       (with-current-buffer nnimap-server-buffer
-	(if force
-	    (progn
-	      (nnimap-expiry-target artseq group server)
-	      (when (imap-message-flags-add (imap-range-to-message-set artseq)
-					    "\\Deleted")
-		(setq articles nil)))
 	  (let ((days (or (and nnmail-expiry-wait-function
 			       (funcall nnmail-expiry-wait-function group))
 			  nnmail-expiry-wait)))
-	    (cond ((eq days 'immediate)
+	  (cond (force
+		 (nnimap-expiry-target artseq group server)
+		 (when (imap-message-flags-add
+			(imap-range-to-message-set artseq) "\\Deleted")
+		   (setq articles nil)))
+		((eq days 'immediate)
 		   (nnimap-expiry-target artseq group server)
 		   (when (imap-message-flags-add
 			  (imap-range-to-message-set artseq) "\\Deleted")
@@ -1340,7 +1342,7 @@ function is generally only called when G
 			    (gnus-compress-sequence oldarts))
 			   "\\Deleted")
 			  (setq articles (gnus-set-difference
-					  articles oldarts)))))))))))
+					articles oldarts))))))))))
   ;; return articles not deleted
   articles)
 

Re: [PATCH] nnmail-fancy-expiry-target

[Nevin Kapur]

Simon Josefsson <jas@extundo.com> writes:

> Nevin Kapur <nevin@jhu.edu> writes:
>
>> Applying this patch gives the following error each time I exit an
>> nnimap group which does not use delete as its expiry-target:
>>
>> Signaling: (error "Buffer  *temp* has no process")
>>   process-send-string(nil "12 STATUS \"mail/Mailbox\" (UIDVALIDITY)\n")
>
> Sorry, try this:

OK, this fixed the error but doesn't solve the original problem.  I
tried to expire to an non-existent group and it didn't create it on
the fly.

I don't understand why you are checking for the existence of the group
from which the expiry is called.  Doesn't that exist by definition?

Shouldn't one be checking for the existence of the group returned by
nnmail-expiry-target?

> --- nnimap.el	2002/07/10 16:28:39	6.37
> +++ nnimap.el	2002/07/29 12:03:00
> @@ -1296,6 +1296,8 @@ function is generally only called when G
>  (defun nnimap-expiry-target (arts group server)
>    (unless (eq nnmail-expiry-target 'delete)
>      (with-temp-buffer
> +      (or (imap-mailbox-status group 'UIDVALIDITY nnimap-server-buffer)
> +	  (imap-mailbox-create group nnimap-server-buffer))
>        (dolist (art (gnus-uncompress-sequence arts))
>  	(nnimap-request-article art group server  (current-buffer))
>  	;; hints for optimization in `nnimap-request-accept-article'

-Nevin