From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Nicolas Graner <nicolas@graner.name>
Cc: 70338@debbugs.gnu.org
Subject: bug#70338: message-fcc-externalize-attachments has no effect
Date: Sat, 20 Apr 2024 17:28:58 -0700 [thread overview]
Message-ID: <878r17h839.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <878r18t022.fsf@graner.name> (Nicolas Graner's message of "Sat, 20 Apr 2024 19:29:25 +0200")
[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]
On 04/20/24 19:29 PM, Nicolas Graner wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> wrote on 2024-04-20 08:36:
>> So far I don't see that this option would actually do anything in an FCC
>> context. `message-fcc-externalize-attachments' is only used in
>> `message-do-fcc`, where its value is let-bound to
>> `mml-externalize-attachments'.
>>
>> But `mml-externalize-attachments' is only consulted in
>> `gnus-inews-do-gcc', which already doesn't sound very promising. That
>> function first let-binds `mml-externalize-attachments' to nil, before
>> doing its own setting, so any dynamic value is getting overridden
>> anyway.
>>
>> I tried starting with `gnus-gcc-externalize-attachments' and sending a
>> message with an attachment, just to see how it's supposed to work.
>> Nothing seemed to happen.
>>
>> Can you tell me what the desired effect is supposed to be? Does the
>> "gcc" version of this option work for you?
>>
>> Eric
>
> When you attach a file to a mail message you are writing, only an anchor
> with the file name is inserted in the message buffer. When the message
> is sent, the anchor is replaced with the actual MIME-encoded contents of
> the attached file. The copy of the message that is written to the FCC
> file also includes the MIME-encoded attached file.
>
> I was expecting that externalization would mean that the copy in the FCC
> file would only include an anchor rather than the attachment, which
> would be extremely useful. I must admit this was only a guess (wishful
> thinking?) since the documentation is not explicit at all.
Oh, that sounds very useful, I've often wanted that.
> I don't use gnus. To test the gnus version of the variable, I guess I
> would need access to a free, public NNTP server, which I don't know
> where to find. Can you help?
I think most of us use news.gmane.io
I tested the GCC version again (now that I know what it's supposed to
do), and it did work -- the version of the message in my Sent folder had
a mime part of "message/external-body".
Long story short, the encoded body of the message is cached during
sending, and the cached version is re-used during GCC/FCC handling. If
the user has requested the externalization of attachments, the GCC
version of the code knows to use that as a flag to dump the cache and
re-generate it with externalized attachments; the FCC code doesn't do
the equivalent.
I've pushed a change that fixes this issue in my testing -- are you
using Emacs master? If not, I've attached the commit here, I hope you'll
be able to test it.
Thanks,
Eric
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Re-encode-message-bodies-with-externalized-attachmen.patch --]
[-- Type: text/x-patch, Size: 1264 bytes --]
From 3dfca6f9c7f4da512fff48cf6957c6492e2c0449 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sat, 20 Apr 2024 17:25:20 -0700
Subject: [PATCH] Re-encode message bodies with externalized attachments during
FCC
Bug#70338
* lisp/gnus/message.el (message-do-fcc): If the user has requested to
externalize attachments, we can't use the cached version of the message
body from sending. This mirrors an equivalent check for GCC in
`gnus-inews-do-gcc'.
---
lisp/gnus/message.el | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 979d2fecf56..b2805774162 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -5768,8 +5768,10 @@ message-do-fcc
(with-temp-buffer
(insert-buffer-substring buf)
(message-clone-locals buf)
- ;; Avoid re-doing things like GPG-encoding secret parts.
- (if (not encoded-cache)
+ ;; Avoid re-doing things like GPG-encoding secret parts, unless
+ ;; the user has requested that attachments be externalized, in
+ ;; which case we have to re-encode the message body.
+ (if (or mml-externalize-attachments (not encoded-cache))
(message-encode-message-body)
(erase-buffer)
(insert encoded-cache))
--
2.44.0
next prev parent reply other threads:[~2024-04-21 0:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 12:39 bug#70338: message-fcc-externalize-attachments has no effect Nicolas Graner
2024-04-18 10:11 ` Eli Zaretskii
2024-04-20 15:36 ` Eric Abrahamsen
2024-04-20 16:20 ` Eli Zaretskii
2024-04-20 16:22 ` Eric Abrahamsen
2024-04-20 17:29 ` Nicolas Graner
2024-04-21 0:28 ` Eric Abrahamsen [this message]
2024-04-22 4:19 ` Nicolas Graner
2024-04-22 4:27 ` Eric Abrahamsen
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=878r17h839.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=70338@debbugs.gnu.org \
--cc=nicolas@graner.name \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.