From: "Rupa Schomaker (list)" <rupa-list@rupa.com>
Subject: why article refresh in gnus-summary-edit-article?
Date: 16 Sep 1999 18:50:48 -0700 [thread overview]
Message-ID: <m3lna6fgqv.fsf@gw.rupa.com> (raw)
[-- 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.
next reply other threads:[~1999-09-17 1:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-17 1:50 Rupa Schomaker (list) [this message]
1999-09-24 16:16 ` Lars Magne Ingebrigtsen
1999-09-24 19:20 ` Rupa Schomaker (list)
1999-09-25 10:12 ` Lars Magne Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3lna6fgqv.fsf@gw.rupa.com \
--to=rupa-list@rupa.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).