all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#70338: message-fcc-externalize-attachments has no effect
@ 2024-04-11 12:39 Nicolas Graner
  2024-04-18 10:11 ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Graner @ 2024-04-11 12:39 UTC (permalink / raw)
  To: 70338

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  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
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2024-04-18 10:11 UTC (permalink / raw)
  To: Nicolas Graner, eric; +Cc: 70338

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  2024-04-18 10:11 ` Eli Zaretskii
@ 2024-04-20 15:36   ` Eric Abrahamsen
  2024-04-20 16:20     ` Eli Zaretskii
  2024-04-20 17:29     ` Nicolas Graner
  0 siblings, 2 replies; 9+ messages in thread
From: Eric Abrahamsen @ 2024-04-20 15:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 70338, Nicolas Graner


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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  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
  1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2024-04-20 16:20 UTC (permalink / raw)
  To: nicolas, Eric Abrahamsen; +Cc: 70338

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  2024-04-20 16:20     ` Eli Zaretskii
@ 2024-04-20 16:22       ` Eric Abrahamsen
  0 siblings, 0 replies; 9+ messages in thread
From: Eric Abrahamsen @ 2024-04-20 16:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 70338, nicolas

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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  2024-04-20 15:36   ` Eric Abrahamsen
  2024-04-20 16:20     ` Eli Zaretskii
@ 2024-04-20 17:29     ` Nicolas Graner
  2024-04-21  0:28       ` Eric Abrahamsen
  1 sibling, 1 reply; 9+ messages in thread
From: Nicolas Graner @ 2024-04-20 17:29 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: eliz, 70338

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  2024-04-20 17:29     ` Nicolas Graner
@ 2024-04-21  0:28       ` Eric Abrahamsen
  2024-04-22  4:19         ` Nicolas Graner
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Abrahamsen @ 2024-04-21  0:28 UTC (permalink / raw)
  To: Nicolas Graner; +Cc: 70338

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


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  2024-04-21  0:28       ` Eric Abrahamsen
@ 2024-04-22  4:19         ` Nicolas Graner
  2024-04-22  4:27           ` Eric Abrahamsen
  0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Graner @ 2024-04-22  4:19 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: 70338

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#70338: message-fcc-externalize-attachments has no effect
  2024-04-22  4:19         ` Nicolas Graner
@ 2024-04-22  4:27           ` Eric Abrahamsen
  0 siblings, 0 replies; 9+ messages in thread
From: Eric Abrahamsen @ 2024-04-22  4:27 UTC (permalink / raw)
  To: Nicolas Graner; +Cc: 70338-done

Nicolas Graner <nicolas@graner.name> writes:

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

Excellent! I'll close the bug report now.





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-04-22  4:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2024-04-22  4:19         ` Nicolas Graner
2024-04-22  4:27           ` Eric Abrahamsen

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.