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