GNU bug report logs - #70338
message-fcc-externalize-attachments has no effect

Previous Next

Full log

Message #23 received at 70338 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Nicolas Graner <nicolas <at> graner.name>
Cc: 70338 <at> debbugs.gnu.org
Subject: Re: bug#70338: message-fcc-externalize-attachments has no effect
Date: Sat, 20 Apr 2024 17:28:58 -0700

[Message part 1 (text/plain, inline)]

On 04/20/24 19:29 PM, Nicolas Graner wrote:
> Eric Abrahamsen <eric <at> 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

[0001-Re-encode-message-bodies-with-externalized-attachmen.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.