bug#70338: message-fcc-externalize-attachments has no effect

bug#70338: message-fcc-externalize-attachments has no effect

[Nicolas Graner]

The variable message-fcc-externalize-attachments seems to have no effect
(tested in emacs 30.0.50). Whether I set it to t or nil, whenever I send
a mail message with a file attached, the file is included as an internal
message part in the FCC mailbox.

I am not sure if this is a bug or if I am missing something, such as
another variable that interferes with this one.

Nicolas

bug#70338: message-fcc-externalize-attachments has no effect

[Eli Zaretskii]

> From: Nicolas Graner <nicolas@graner.name>
> Date: Thu, 11 Apr 2024 14:39:12 +0200
> 
> The variable message-fcc-externalize-attachments seems to have no effect
> (tested in emacs 30.0.50). Whether I set it to t or nil, whenever I send
> a mail message with a file attached, the file is included as an internal
> message part in the FCC mailbox.
> 
> I am not sure if this is a bug or if I am missing something, such as
> another variable that interferes with this one.

Eric, can you please look into this?

Thanks.

bug#70338: message-fcc-externalize-attachments has no effect

[Eric Abrahamsen]

On 04/18/24 13:11 PM, Eli Zaretskii wrote:
>> From: Nicolas Graner <nicolas@graner.name>
>> Date: Thu, 11 Apr 2024 14:39:12 +0200
>> 
>> The variable message-fcc-externalize-attachments seems to have no effect
>> (tested in emacs 30.0.50). Whether I set it to t or nil, whenever I send
>> a mail message with a file attached, the file is included as an internal
>> message part in the FCC mailbox.
>> 
>> I am not sure if this is a bug or if I am missing something, such as
>> another variable that interferes with this one.
>
> Eric, can you please look into this?

I'm trying to figure out what "externalization" is actually supposed to
do. 

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

bug#70338: message-fcc-externalize-attachments has no effect

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Nicolas Graner <nicolas@graner.name>,  70338@debbugs.gnu.org
> Date: Sat, 20 Apr 2024 08:36:40 -0700
> 
> Can you tell me what the desired effect is supposed to be? Does the
> "gcc" version of this option work for you?

I guess you are asking Nicolas, not me?  Because I don't use these
features (and don't use message.el at all).

Nicolas, can you please answer Eric's question?

bug#70338: message-fcc-externalize-attachments has no effect

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: Nicolas Graner <nicolas@graner.name>,  70338@debbugs.gnu.org
>> Date: Sat, 20 Apr 2024 08:36:40 -0700
>> 
>> Can you tell me what the desired effect is supposed to be? Does the
>> "gcc" version of this option work for you?
>
> I guess you are asking Nicolas, not me?  Because I don't use these
> features (and don't use message.el at all).
>
> Nicolas, can you please answer Eric's question?

Yes, sorry, that was aimed at Nicolas.

bug#70338: message-fcc-externalize-attachments has no effect

[Nicolas Graner]

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.

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?

Nicolas

bug#70338: message-fcc-externalize-attachments has no effect

[Eric Abrahamsen]

[-- 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

bug#70338: message-fcc-externalize-attachments has no effect

[Nicolas Graner]

Yes, your patch works for me.
Great, thanks!

Nicolas

Eric Abrahamsen <eric@ericabrahamsen.net> wrote on 2024-04-20 17:28:
> 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

bug#70338: message-fcc-externalize-attachments has no effect

[Eric Abrahamsen]

Nicolas Graner <nicolas@graner.name> writes:

> Yes, your patch works for me.
> Great, thanks!

Excellent! I'll close the bug report now.