why article refresh in gnus-summary-edit-article?

why article refresh in gnus-summary-edit-article?

[Rupa Schomaker (list)]

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

I'm working on enhancing mailcrypt (support pgp 6.x, "better" remailer
support, blah blah) and I'm trying to understand why, at the start of
gnus-summary-edit-article the function (gnus-summary-show-article t)
is called.

I need to decrypt a message (perhaps) multiple times recursively.
Each successive decryption is applied to the current article.
mailcrypt calls gnus-summary-edit-article in order to do this.

To complicate matters, I use nnimap as my backend.  This backend does
not support writes.  So, rather than calling
gnus-summary-edit-article-done mailcrypt calls
gnus-summary-edit-article-postpone.  I suppose if the -done function
was called (and the backend supported editing) then the decryption
would be saved to the message store and subsequent calles to the base
-edit function would behave as expected.

Anyway, using -postpone, the next call to gnus-summary-edit-article
causes the article to be refreshed from the message store.  End of
recursive decoding since we'll allways be decoding the original
message rather than each intermediate step of the decoding process....

I'm not sure what would break if we didn't reload the article before
calling the -edit base.  Anyone know?

Attached is the "patch" if you can call it that.  I'd appreciate
knowing why this should not be applied...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Do not reload article when gnus-summary-article-edit is called --]
[-- Type: text/x-patch, Size: 618 bytes --]

Index: gnus-sum.el
===================================================================
RCS file: /home/cvs/cvsroot/elisp/pgnus/lisp/gnus-sum.el,v
retrieving revision 1.1.1.4
retrieving revision 1.2
diff -u -r1.1.1.4 -r1.2
--- gnus-sum.el	1999/09/03 18:17:36	1.1.1.4
+++ gnus-sum.el	1999/09/17 00:51:27	1.2
@@ -7643,7 +7643,7 @@
       (when (and (not force)
 		 (gnus-group-read-only-p))
 	(error "The current newsgroup does not support article editing"))
-      (gnus-summary-show-article t)
+;      (gnus-summary-show-article t)
       (gnus-article-edit-article
        'mime-to-mml
        `(lambda (no-highlight)

[-- Attachment #3: Type: text/plain, Size: 81 bytes --]


-- 
Rupa (rupa@rupa.com for normal email)
Please don't email duplicate replies.

Re: why article refresh in gnus-summary-edit-article?

[Lars Magne Ingebrigtsen]

"Rupa Schomaker (list)" <rupa-list@rupa.com> writes:

> I'm not sure what would break if we didn't reload the article before
> calling the -edit base.  Anyone know?

Well, you would face having to edit something that has been washed
pretty severly.  For instance, many of the headers would be gone, and
so on.

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

Re: why article refresh in gnus-summary-edit-article?

[Rupa Schomaker (list)]

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

> "Rupa Schomaker (list)" <rupa-list@rupa.com> writes:
> 
> > I'm not sure what would break if we didn't reload the article before
> > calling the -edit base.  Anyone know?
> 
> Well, you would face having to edit something that has been washed
> pretty severly.  For instance, many of the headers would be gone, and
> so on.

Ah, very good point!  <ponder>  The last thing I really want to happen 
is for the decrypted message to actually be saved to the message store 
(currently I think this does happen for backends that support
editing).  Would it be reasonable to add an optional argument to -edit 
that tells it not to do a reload of the article.  Then something that
wants to do the -edit and *knows* that it shouldn't do an article
reload could communicate that fact to -edit...

-- 
Rupa (rupa@rupa.com for normal email)
Please don't email duplicate replies.

Re: why article refresh in gnus-summary-edit-article?

[Lars Magne Ingebrigtsen]

"Rupa Schomaker (list)" <rupa-list@rupa.com> writes:

> The last thing I really want to happen is for the decrypted message
> to actually be saved to the message store (currently I think this
> does happen for backends that support editing).  Would it be
> reasonable to add an optional argument to -edit that tells it not to
> do a reload of the article.  Then something that wants to do the
> -edit and *knows* that it shouldn't do an article reload could
> communicate that fact to -edit...

I don't know whether that would be generally useful.  I think it might 
be better for you to alter the functions to do what you want them to
do... 

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