editing nnimap articles

editing nnimap articles

[Dan Christensen]

I receive so many attachments that I find it necessary to use
gnus-mime-save-part-and-strip to delete them from my archived messages.
I'm in the process of converting from nnfolder to nnimap, and so I'd
like to investigate how hard it would be to extend nnimap to allow
article editing.  

My sense is that it should not be hard, since it just requires the
creation of a new article and the deletion of the old one, and both of
those are operations that nnimap can perform.  (In fact, I just noticed
that `B I' is able to create a new empty article in an nnimap group.)

In digging through the code, it looks to me like what would be needed
would be an implementation of nnimap-request-replace-article.
Would that just be a matter of combining nnimap-request-accept-article
with something like

           (imap-message-flags-add (format "%d" article)
                                   "\\Seen \\Deleted")
?

Would this work?  Can someone help me fill in the details?

Thanks,

Dan

Re: editing nnimap articles

[Ted Zlatanov]

On Thu, 08 Oct 2009 15:05:34 -0400 Dan Christensen <jdc@uwo.ca> wrote: 

DC> I receive so many attachments that I find it necessary to use
DC> gnus-mime-save-part-and-strip to delete them from my archived messages.
DC> I'm in the process of converting from nnfolder to nnimap, and so I'd
DC> like to investigate how hard it would be to extend nnimap to allow
DC> article editing.  

DC> My sense is that it should not be hard, since it just requires the
DC> creation of a new article and the deletion of the old one, and both of
DC> those are operations that nnimap can perform.  (In fact, I just noticed
DC> that `B I' is able to create a new empty article in an nnimap group.)

DC> In digging through the code, it looks to me like what would be needed
DC> would be an implementation of nnimap-request-replace-article.
DC> Would that just be a matter of combining nnimap-request-accept-article
DC> with something like

DC>            (imap-message-flags-add (format "%d" article)
DC>                                    "\\Seen \\Deleted")
DC> ?

DC> Would this work?  Can someone help me fill in the details?

With IMAP, you have to expunge as well, but then you may expunge other
deleted articles at the wrong time.  So you may just have to live with
the old \\Deleted article until the next time the user or Gnus expunges
the group, and it will still show up in the summary buffer.  I think
that's acceptable.

It would be good if this edit told the registry about the changeover by
getting the record for the old message ID and storing it with the new
one.  I can add that hook.

Otherwise this looks good to me, I'm all for it.  I've been doing it the
roundabout way (move to nnmaildir, edit, move back) for years.

Ted

Re: editing nnimap articles

[David Engster]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 08 Oct 2009 15:05:34 -0400 Dan Christensen <jdc@uwo.ca> wrote: 
> DC> I receive so many attachments that I find it necessary to use
> DC> gnus-mime-save-part-and-strip to delete them from my archived messages.
> DC> I'm in the process of converting from nnfolder to nnimap, and so I'd
> DC> like to investigate how hard it would be to extend nnimap to allow
> DC> article editing.  

[...]

> DC> In digging through the code, it looks to me like what would be needed
> DC> would be an implementation of nnimap-request-replace-article.
> DC> Would that just be a matter of combining nnimap-request-accept-article
> DC> with something like
>
> DC>            (imap-message-flags-add (format "%d" article)
> DC>                                    "\\Seen \\Deleted")
> DC> ?
>
> DC> Would this work?  Can someone help me fill in the details?

[...]

> Otherwise this looks good to me, I'm all for it.  I've been doing it the
> roundabout way (move to nnmaildir, edit, move back) for years.

The problem is that the *-request-replace-article function is required
to really *replace* the article, i.e., the article number must remain
the same. This is not possible with IMAP.

I would also welcome a 'strip attachments' function for IMAP, but it
shouldn't be done through a nnimap-request-replace-article function.

Regards,
David

Re: editing nnimap articles

[Ted Zlatanov]

On Fri, 09 Oct 2009 16:48:21 +0200 David Engster <deng@randomsample.de> wrote: 

DE> The problem is that the *-request-replace-article function is required
DE> to really *replace* the article, i.e., the article number must remain
DE> the same. This is not possible with IMAP.

Looking at gnus-request-replace-article, I don't see a problem if the
function returns nil.  So, if nnimap-request-replace-article returns nil
and (as a side effect) deletes the old article and creates the new one,
that should do what the user expects.  It's not ideal but I think it's
better than a new special gnus-request-replace-by-appending-article
function or a new flag for gnus-request-replace-article.

All of this is untested, so please tell me if I'm speaking nonsense.

Ted

Re: editing nnimap articles

[David Engster]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 09 Oct 2009 16:48:21 +0200 David Engster <deng@randomsample.de> wrote: 
>
> DE> The problem is that the *-request-replace-article function is required
> DE> to really *replace* the article, i.e., the article number must remain
> DE> the same. This is not possible with IMAP.
>
> Looking at gnus-request-replace-article, I don't see a problem if the
> function returns nil.  So, if nnimap-request-replace-article returns nil
> and (as a side effect) deletes the old article and creates the new one,
> that should do what the user expects.  It's not ideal but I think it's
> better than a new special gnus-request-replace-by-appending-article
> function or a new flag for gnus-request-replace-article.

The return value is not a problem; 'request-replace-article' is not
supposed to return any data. But the docs say:

`(nnchoke-request-replace-article ARTICLE GROUP BUFFER)'
     This function should remove ARTICLE (which is a number) from GROUP
     and insert BUFFER there instead.

     There should be no data returned.

While not explicitly stated, I read this in the sense that the article
number stays the same. I admit I do not know if there is any code in (or
outside) Gnus which depends on that, but I'm just uncomfortable with
implementing article editing for a mail protocol which simply doesn't
support it (even forbids it). I think it would be better to implement
this outside the back end API. Just my opinion, though. :-)

Regards,
David

Re: editing nnimap articles

[Ted Zlatanov]

On Fri, 09 Oct 2009 17:29:11 +0200 David Engster <deng@randomsample.de> wrote: 

DE> The return value is not a problem; 'request-replace-article' is not
DE> supposed to return any data. But the docs say:

DE> `(nnchoke-request-replace-article ARTICLE GROUP BUFFER)'
DE>      This function should remove ARTICLE (which is a number) from GROUP
DE>      and insert BUFFER there instead.

DE>      There should be no data returned.

DE> While not explicitly stated, I read this in the sense that the article
DE> number stays the same. 

...and it does, it's just that we delete that article and the contents
are not modified.  That should all be OK.

DE> I admit I do not know if there is any code in (or outside) Gnus
DE> which depends on that, but I'm just uncomfortable with implementing
DE> article editing for a mail protocol which simply doesn't support it
DE> (even forbids it). I think it would be better to implement this
DE> outside the back end API. Just my opinion, though. :-)

Our users, myself included, have needed this functionality for years.
Obviously it's available by moving the article out, editing in another
backend, and moving it back, so we're just making it easier.  If you
think `e' in IMAP groups should do something special (that's how I
understand your suggestion about "outside"), that's possible too.

I'd rather have it go through the backend so the agent, registry, and
any hooks have a chance to get run.  But I'm easily swayed: why
shouldn't it go through the backend, besides feeling hacky?

Ted

Re: editing nnimap articles

[Dan Christensen]

One advantage of doing it with request-replace-article is that several
things all start working:

- plain editing
- strip and save attachments
- `B I' and related commands

etc.

On the other hand, we could instead create a new backend function
request-replace-append, which by default just calls request-replace but
is overridden by nnimap.  I think only one place would need to be
changed in the edit call graph in order to make all of the operations
above start working for nnimap.

But unless there is a specific problem with just implementing
request-replace for nnimap, I would go with the more direct solution.
(However, I only know the Gnus internals at a very superficial level,
so don't put much weight on my opinion.)

Dan

Re: editing nnimap articles

[David Engster]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 09 Oct 2009 17:29:11 +0200 David Engster <deng@randomsample.de> wrote: 
>
> DE> The return value is not a problem; 'request-replace-article' is not
> DE> supposed to return any data. But the docs say:
>
> DE> `(nnchoke-request-replace-article ARTICLE GROUP BUFFER)'
> DE>      This function should remove ARTICLE (which is a number) from GROUP
> DE>      and insert BUFFER there instead.
>
> DE>      There should be no data returned.
>
> DE> While not explicitly stated, I read this in the sense that the article
> DE> number stays the same. 
>
> ...and it does, it's just that we delete that article and the contents
> are not modified.  That should all be OK.

Maybe I'm understanding something wrong here. Say you'd like to edit the
mail with article number '10' in INBOX. So you hit 'e' and edit
away. After committing the change, the mail number '10' will not exist
anymore, but there will be a new article, containing the edited text,
but with an article number whatever the IMAP server chose to use (as
long as it wasn't used before).

Therefore, you did not really 'edit' the article, but created a new
one.

Regards,
David

Re: editing nnimap articles

[Ted Zlatanov]

On Fri, 09 Oct 2009 20:53:47 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Maybe I'm understanding something wrong here. Say you'd like to edit the
DE> mail with article number '10' in INBOX. So you hit 'e' and edit
DE> away. After committing the change, the mail number '10' will not exist
DE> anymore, but there will be a new article, containing the edited text,
DE> but with an article number whatever the IMAP server chose to use (as
DE> long as it wasn't used before).

DE> Therefore, you did not really 'edit' the article, but created a new
DE> one.

Right.  The proposal will make replacing the article fail and as a side
effect create a new one and delete this one.  I think it's justified;
why shouldn't we do it?  Does it break anything?

On Fri, 09 Oct 2009 12:07:44 -0400 Dan Christensen <jdc@uwo.ca> wrote: 

DC> One advantage of doing it with request-replace-article is that several
DC> things all start working:

DC> - plain editing
DC> - strip and save attachments
DC> - `B I' and related commands

DC> etc.

DC> On the other hand, we could instead create a new backend function
DC> request-replace-append, which by default just calls request-replace but
DC> is overridden by nnimap.  I think only one place would need to be
DC> changed in the edit call graph in order to make all of the operations
DC> above start working for nnimap.

DC> But unless there is a specific problem with just implementing
DC> request-replace for nnimap, I would go with the more direct solution.
DC> (However, I only know the Gnus internals at a very superficial level,
DC> so don't put much weight on my opinion.)

As far as I understand the internals, I think adding a new backend
function for the sake of IMAP is not worth it.  It's less effort to
change the docs to explain the exception as long as it's just one
exception.  As soon as it extends to 2 or more, it's time to refactor.

We could also make the functionality more generic by indicating (as a
backend nnvoo parameter) that the backend is append-only.  Then we still
use request-replace but it's less magical and other functions can look
at that parameter.

Ted

Re: editing nnimap articles

[Dan Christensen]

I suggest we try it and see whether anything breaks.  If something
breaks, it'll be easy to copy the code from request-replace to a new
function.

So, can someone give pointers about how to proceed?  I'll see what I
can come up with, but having never used nnimap (or looked at the code)
before a few days ago, some tips would speed things up.

Thanks,

Dan

Re: editing nnimap articles

[Dan Christensen]

Dan Christensen <jdc@uwo.ca> writes:

> I suggest we try it and see whether anything breaks.  If something
> breaks, it'll be easy to copy the code from request-replace to a new
> function.
>
> So, can someone give pointers about how to proceed?  I'll see what I
> can come up with, but having never used nnimap (or looked at the code)
> before a few days ago, some tips would speed things up.

Here's a very rough attempt, that is already useful:

(deffoo nnimap-request-replace-article (article group buffer)
  (and (with-current-buffer buffer
	 (nnimap-request-accept-article group))
       (nnimap-possibly-change-group group)
       (imap-message-flags-add
	(imap-range-to-message-set (list article))
	"\\Deleted" 'silent nnimap-server-buffer)))

Some important missing things:

- copying the marks
- refreshing the summary buffer to exclude the Deleted article and
  include the new article
- documentation
- registry?
- nov handling?
- anything else?

It occurred to me that what this does is very close to what `B m'
(gnus-summary-move-article) does, except that we use our newly edited
buffer instead of the original article.  Maybe we can set a global
variable such as nnimap-request-accept-buffer to the buffer containing
the replacement, adjust nnimap-request-article to notice this and use
that buffer instead of the current buffer, and then just call
gnus-summary-move-article?  It should already handle copying the marks,
and most other things that needs to be done (except refreshing the
summary buffer).  I tried to do it this way in the enclosed patch, but I
get an error I haven't been able to figure out (see below).

Dan

--- nnimap.orig.el	2009-09-30 12:56:46.000000000 -0400
+++ nnimap.el	2009-10-09 21:57:02.000000000 -0400
@@ -1564,6 +1563,7 @@
 	    (nnimap-current-move-article article)
 	    (nnimap-current-move-group group)
 	    (nnimap-current-move-server nnimap-current-server)
+	    (move-is-internal (and move-is-internal (not nnimap-request-accept-buffer)))
 	    result)
 	(gnus-message 10 "nnimap-request-move-article: this is an %s move"
 		      (if move-is-internal
@@ -1584,6 +1584,7 @@
 	      "\\Deleted" 'silent nnimap-server-buffer))
 	result))))
 
+(setq nnimap-request-accept-buffer nil)
 (deffoo nnimap-request-accept-article (group &optional server last)
   (when (nnimap-possibly-change-server server)
     (let (uid)
@@ -1596,7 +1597,7 @@
 					     nnimap-current-move-article)
 					    group 'dontcreate nil
 					    nnimap-server-buffer))
-		  (with-current-buffer (current-buffer)
+		  (with-current-buffer (or nnimap-request-accept-buffer (current-buffer))
 		    (goto-char (point-min))
 		    ;; remove any 'From blabla' lines, some IMAP servers
 		    ;; reject the entire message otherwise.
@@ -1619,6 +1620,14 @@
 	  (cons group (nth 1 uid))
 	(nnheader-report 'nnimap (imap-error-text nnimap-server-buffer))))))
 
+(deffoo nnimap-request-replace-article (article group buffer)
+  (let ((nnimap-request-accept-buffer buffer)
+	(gnusgroup (gnus-group-prefixed-name
+		    group (gnus-server-to-method
+			   (format "nnimap:%s" nnimap-current-server)))))
+    (nnimap-request-article article group)
+    (gnus-summary-move-article 1 gnusgroup)))
+
 (deffoo nnimap-request-delete-group (group force &optional server)
   (when (nnimap-possibly-change-server server)
     (when (string= group (imap-current-mailbox nnimap-server-buffer))


Debugger entered--Lisp error: (wrong-type-argument consp nil)
  gnus-summary-move-article(1 "nnimap+jdc:test")
  (let ((nnimap-request-accept-buffer buffer) (gnusgroup ...)) (nnimap-request-article article group) (message "gnusgroup %s" gnusgroup) (gnus-summary-move-article 1 gnusgroup))
  ad-Orig-nnimap-request-replace-article(1906 "test" #<buffer  *temp*>)
  nnimap-request-replace-article(1906 "test" #<buffer  *temp*>)
  gnus-request-replace-article(1906 "nnimap+jdc:test" #<buffer  *temp*> t)
  gnus-summary-edit-article-done("" nil #<buffer *Summary nnimap+jdc:test*> nil)
  (let ((mail-parse-charset ...) (message-options message-options) (message-options-set-recipient) (mail-parse-ignored-charsets ...) (rfc2047-header-encoding-alist ...)) (progn (mml-to-mime) (mml-destroy-buffers) (remove-hook ... ... t) (kill-local-variable ...)) (gnus-summary-edit-article-done "" nil #<buffer *Summary nnimap+jdc:test*> no-highlight))
  (lambda (no-highlight) (let (... ... ... ... ...) (progn ... ... ... ...) (gnus-summary-edit-article-done "" nil #<buffer *Summary nnimap+jdc:test*> no-highlight)))(nil)
  gnus-article-edit-done(nil)
  call-interactively(gnus-article-edit-done nil nil)

Re: editing nnimap articles

[David Engster]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 09 Oct 2009 20:53:47 +0200 David Engster <deng@randomsample.de> wrote: 
>
> DE> Maybe I'm understanding something wrong here. Say you'd like to edit the
> DE> mail with article number '10' in INBOX. So you hit 'e' and edit
> DE> away. After committing the change, the mail number '10' will not exist
> DE> anymore, but there will be a new article, containing the edited text,
> DE> but with an article number whatever the IMAP server chose to use (as
> DE> long as it wasn't used before).
>
> DE> Therefore, you did not really 'edit' the article, but created a new
> DE> one.
>
> Right.  The proposal will make replacing the article fail and as a side
> effect create a new one and delete this one.

OK, I think I get it now.  I was under the impression the
delete-and-create workaround was meant to be "the replacement", but if
the replacement actually fails and the creation of the edited article
it's just a side effect, I think this should be OK.

>  I think it's justified; why shouldn't we do it?  Does it break
> anything?

I don't know. :-) It might have some surprising consequences, e.g., if
people sort 'by number', edited article will probably appear as
newest. But that's a minor thing, and sorting by number with nnimap was
always problematical, since it's entirely up to the server how he
chooses the article IDs.

As Dan already wrote: implement it, and see what happens. :-)

> As far as I understand the internals, I think adding a new backend
> function for the sake of IMAP is not worth it.  It's less effort to
> change the docs to explain the exception as long as it's just one
> exception.  As soon as it extends to 2 or more, it's time to refactor.

I agree.

Regards,
David

Re: editing nnimap articles

[Dan Christensen]

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

Here's a slightly improved attempt to allow article editing using IMAP.
I copied some code from gnus-summary-move-article to flag the deleted
article with gnus-canceled-mark, and I also call
gnus-summary-insert-new-articles.

(deffoo nnimap-request-replace-article (article group buffer)
  (and (with-current-buffer buffer
	 (nnimap-request-accept-article group))

       (nnimap-possibly-change-group group)
       (imap-message-flags-add
	(imap-range-to-message-set (list article))
	"\\Deleted" 'silent nnimap-server-buffer)

       (set-buffer gnus-summary-buffer)
       (gnus-summary-goto-subject article)
       (gnus-summary-mark-article article gnus-canceled-mark)
       (gnus-summary-insert-new-articles)
       (gnus-summary-position-point)
       (gnus-set-mode-line 'summary)))

Some things still missing:

- copy the marks
- select the new article
- documentation
- registry?
- nov handling?
- dribble buffer?
- anything else?

But gnus-summary-move-article is 291 lines long, so I'm still thinking
that since we really are moving the article, it would be better to
simply call gnus-summary-move-article instead of reproducing a lot of
the functionality, by having a flag indicating that a different buffer
should be used for the destination article.  My attempt at doing this
(patch below) doesn't work, probably because of some assumptions about
context when some functions are called.  However I suspect it shouldn't
be too hard to fix, if I understood the problem.  I currently get the
following backtrace:

  setcdr(nil 29)
  (progn (push (cons to-article gnus-read-mark) gnus-newsgroup-reads) (setcdr (gnus-active to-group) to-article) (setcdr gnus-newsgroup-active to-article))
  (if (and (equal to-group gnus-newsgroup-name) (not ...)) (progn (push ... gnus-newsgroup-reads) (setcdr ... to-article) (setcdr gnus-newsgroup-active to-article)))
  (when (and (equal to-group gnus-newsgroup-name) (not ...)) (push (cons to-article gnus-read-mark) gnus-newsgroup-reads) (setcdr (gnus-active to-group) to-article) (setcdr gnus-newsgroup-active to-article))
  (progn (when (and ... ...) (push ... gnus-newsgroup-reads) (setcdr ... to-article) (setcdr gnus-newsgroup-active to-article)) (while marks (when ... ...) (setq marks ...)) (when (and expirable gnus-mark-copied-or-moved-articles-as-expirable ...) (push ... to-marks) (when ... ...) (gnus-add-marked-articles to-group ... ... info)) (gnus-request-set-mark to-group (list ...)))
  (if gnus-preserve-marks (progn (when ... ... ... ...) (while marks ... ...) (when ... ... ... ...) (gnus-request-set-mark to-group ...)))
  (when gnus-preserve-marks (when (and ... ...) (push ... gnus-newsgroup-reads) (setcdr ... to-article) (setcdr gnus-newsgroup-active to-article)) (while marks (when ... ...) (setq marks ...)) (when (and expirable gnus-mark-copied-or-moved-articles-as-expirable ...) (push ... to-marks) (when ... ...) (gnus-add-marked-articles to-group ... ... info)) (gnus-request-set-mark to-group (list ...)))
  (let* ((expirable ...) (marks ...) (to-article ...)) (when gnus-use-cache (gnus-cache-possibly-enter-article to-group to-article ... ... ...)) (when gnus-preserve-marks (when ... ... ... ...) (while marks ... ...) (when ... ... ... ...) (gnus-request-set-mark to-group ...)) (gnus-dribble-enter (concat "(gnus-group-set-info '" ... ")")))
  (progn (unless (member to-group to-groups) (push to-group to-groups)) (unless (memq article gnus-newsgroup-unreads) (push ... to-marks) (gnus-info-set-read info ...)) (let* (... ... ...) (when gnus-use-cache ...) (when gnus-preserve-marks ... ... ... ...) (gnus-dribble-enter ...)))
  (if (and info (memq action ...)) (progn (unless ... ...) (unless ... ... ...) (let* ... ... ... ...)))
  (when (and info (memq action ...)) (unless (member to-group to-groups) (push to-group to-groups)) (unless (memq article gnus-newsgroup-unreads) (push ... to-marks) (gnus-info-set-read info ...)) (let* (... ... ...) (when gnus-use-cache ...) (when gnus-preserve-marks ... ... ... ...) (gnus-dribble-enter ...)))
  (let* ((pto-group ...) (info ...) (to-group ...) to-marks) (when (and info ...) (unless ... ...) (unless ... ... ...) (let* ... ... ... ...)) (when (eq action ...) (with-current-buffer copy-buf ... ... ...)) (run-hook-with-args (quote gnus-summary-article-move-hook) action (gnus-data-header ...) gnus-newsgroup-name to-newsgroup select-method))
  (cond ((not art-group) (gnus-message 1 "Couldn't %s article %s: %s" ... article ...)) ((eq art-group ...) (when ... ... ... ...)) (t (let* ... ... ... ...) (set-buffer gnus-summary-buffer) (gnus-summary-goto-subject article) (when ... ...)))
  (while articles (setq article (pop articles)) (setq art-group (cond ... ... ...)) (cond (... ...) (... ...) (t ... ... ... ...)) (push article articles-to-update-marks))
  (let ((articles ...) (prefix ...) (names ...) (copy-buf ...) art-group to-method new-xref article to-groups articles-to-update-marks encoded) (unless (assq action names) (error "Unknown action %s" action)) (when (and ... ...) (if ... ...) (setq to-newsgroup ... encoded to-newsgroup to-method ...) (set ... ...)) (unless to-method (setq to-method ...)) (setq to-newsgroup (or encoded ...)) (unless (gnus-check-backend-function ... ...) (error "%s does not support article copying" ...)) (unless (gnus-check-server to-method) (error "Can't open server %s" ...)) (gnus-message 6 "%s to %s: %s..." (caddr ...) (or ... ...) articles) (while articles (setq article ...) (setq art-group ...) (cond ... ... ...) (push article articles-to-update-marks)) (apply (quote gnus-summary-remove-process-mark) arti
 cles-to-update-marks) (with-current-buffer gnus-group-buffer (let ... ...)) (gnus-kill-buffer copy-buf) (gnus-summary-position-point) (gnus-set-mode-line (quote summary)))
  gnus-summary-move-article(1 "nnimap+rocky:test")
  nnimap-request-replace-article(28 "test" #<buffer  *temp*>)
  gnus-request-replace-article(28 "nnimap+rocky:test" #<buffer  *temp*> t)
  (not (gnus-request-replace-article (cdr gnus-article-current) (car gnus-article-current) (current-buffer) t))
  (and (not read-only) (not (gnus-request-replace-article ... ... ... t)))
  (if (and (not read-only) (not ...)) (error "Couldn't replace article") (if (and references ...) (save-excursion ...) (set-buffer ...) (gnus-summary-update-article ...) (if ... ...)) (unless no-highlight (with-current-buffer gnus-article-buffer ... ...)) (when (gnus-visual-p ... ...) (gnus-run-hooks ...)))
  (progn (insert-buffer-substring buf) (if (and ... ...) (error "Couldn't replace article") (if ... ... ... ... ...) (unless no-highlight ...) (when ... ...)))
  (unwind-protect (progn (insert-buffer-substring buf) (if ... ... ... ... ...)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn ... ...) (and ... ...)))
  (with-current-buffer temp-buffer (unwind-protect (progn ... ...) (and ... ...)))
  (let ((temp-buffer ...)) (with-current-buffer temp-buffer (unwind-protect ... ...)))
  (with-temp-buffer (insert-buffer-substring buf) (if (and ... ...) (error "Couldn't replace article") (if ... ... ... ... ...) (unless no-highlight ...) (when ... ...)))
  (let ((buf ...)) (with-temp-buffer (insert-buffer-substring buf) (if ... ... ... ... ...)))
  gnus-summary-edit-article-done("<20091016164135.GA24802@homotopy13.math.uwo.ca> <b0fdd0cf0910160959g684e31a6i540de7c479cb6c2e@mail.gmail.com> <87r5t0u3xs.fsf@uwo.ca> <b0fdd0cf0910190657k176a415u1d138dbe3594b262@mail.gmail.com> <87tyxvv0ne.fsf@jdc.math.uwo.ca>" nil #<buffer *Summary nnimap+rocky:test*> nil)
  (let ((mail-parse-charset ...) (message-options message-options) (message-options-set-recipient) (mail-parse-ignored-charsets ...) (rfc2047-header-encoding-alist ...)) (progn (mml-to-mime) (mml-destroy-buffers) (remove-hook ... ... t) (kill-local-variable ...)) (gnus-summary-edit-article-done "<20091016164135.GA24802@homotopy13.math.uwo.ca> <b0fdd0cf0910160959g684e31a6i540de7c479cb6c2e@mail.gmail.com> <87r5t0u3xs.fsf@uwo.ca> <b0fdd0cf0910190657k176a415u1d138dbe3594b262@mail.gmail.com> <87tyxvv0ne.fsf@jdc.math.uwo.ca>" nil #<buffer *Summary nnimap+rocky:test*> no-highlight))
  (lambda (no-highlight) (let (... ... ... ... ...) (progn ... ... ... ...) (gnus-summary-edit-article-done "<20091016164135.GA24802@homotopy13.math.uwo.ca> <b0fdd0cf0910160959g684e31a6i540de7c479cb6c2e@mail.gmail.com> <87r5t0u3xs.fsf@uwo.ca> <b0fdd0cf0910190657k176a415u1d138dbe3594b262@mail.gmail.com> <87tyxvv0ne.fsf@jdc.math.uwo.ca>" nil #<buffer *Summary nnimap+rocky:test*> no-highlight)))(nil)
  gnus-article-edit-done(nil)
  call-interactively(gnus-article-edit-done nil nil)

Thanks for any help.

Dan


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nnimap.el.diff --]
[-- Type: text/x-diff, Size: 2549 bytes --]

--- nnimap.orig.el	2009-09-30 12:56:46.000000000 -0400
+++ nnimap-nogood.el	2009-10-24 20:42:16.000000000 -0400
@@ -52,7 +52,6 @@
 ;;   o IMAP2BIS compatibility? (RFC2061)
 ;;   o ACAP stuff (perhaps a different project, would be nice to ACAPify
 ;;     .newsrc.eld)
-;;   o What about Gnus's article editing, can we support it?  NO!
 ;;   o Use \Draft to support the draft group??
 ;;   o Duplicate suppression
 ;;   o Rewrite UID SEARCH UID X as UID FETCH X (UID) for those with slow servers
@@ -1564,6 +1563,7 @@
 	    (nnimap-current-move-article article)
 	    (nnimap-current-move-group group)
 	    (nnimap-current-move-server nnimap-current-server)
+	    (move-is-internal (and move-is-internal (not nnimap-request-accept-buffer)))
 	    result)
 	(gnus-message 10 "nnimap-request-move-article: this is an %s move"
 		      (if move-is-internal
@@ -1584,6 +1584,7 @@
 	      "\\Deleted" 'silent nnimap-server-buffer))
 	result))))
 
+(setq nnimap-request-accept-buffer nil)
 (deffoo nnimap-request-accept-article (group &optional server last)
   (when (nnimap-possibly-change-server server)
     (let (uid)
@@ -1596,7 +1597,7 @@
 					     nnimap-current-move-article)
 					    group 'dontcreate nil
 					    nnimap-server-buffer))
-		  (with-current-buffer (current-buffer)
+		  (with-current-buffer (or nnimap-request-accept-buffer (current-buffer))
 		    (goto-char (point-min))
 		    ;; remove any 'From blabla' lines, some IMAP servers
 		    ;; reject the entire message otherwise.
@@ -1619,6 +1620,16 @@
 	  (cons group (nth 1 uid))
 	(nnheader-report 'nnimap (imap-error-text nnimap-server-buffer))))))
 
+(deffoo nnimap-request-replace-article (article group buffer)
+  (let ((nnimap-request-accept-buffer buffer)
+	(gnusgroup (gnus-group-prefixed-name
+		    group (gnus-server-to-method
+			   (format "nnimap:%s" nnimap-current-server)))))
+    ; With or without the next line I get a backtrace, but it changes:
+    ;(nnimap-request-article article group)
+    (message "%s" (list article group nnimap-request-accept-buffer gnusgroup))
+    (gnus-summary-move-article 1 gnusgroup)))
+
 (deffoo nnimap-request-delete-group (group force &optional server)
   (when (nnimap-possibly-change-server server)
     (when (string= group (imap-current-mailbox nnimap-server-buffer))
@@ -1789,6 +1800,7 @@
 	  nnimap-request-expire-articles
 	  nnimap-request-move-article
 	  nnimap-request-accept-article
+	  nnimap-request-replace-article
 	  nnimap-request-delete-group
 	  nnimap-request-rename-group
 	  gnus-group-nnimap-expunge