GNU bug report logs - #78971
[PATCH] New hook run after saving Rmail MIME attachments

Previous Next

Package: emacs;

Reported by: "Paul D. Nelson" <ultrono <at> gmail.com>

Date: Mon, 7 Jul 2025 08:17:02 UTC

Severity: normal

Tags: patch

To reply to this bug, email your comments to 78971 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#78971; Package emacs. (Mon, 07 Jul 2025 08:17:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Paul D. Nelson" <ultrono <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 07 Jul 2025 08:17:02 GMT) Full text and rfc822 format available.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] New hook run after saving Rmail MIME attachments
Date: Mon, 07 Jul 2025 10:16:40 +0200
[Message part 1 (text/plain, inline)]
This patch adds a hook run after saving attachments in Rmail.  The
motivation is to be able to perform post-save actions, such as jumping
to the attachment in Dired.

[0001-New-hook-run-after-saving-Rmail-MIME-attachments.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78971; Package emacs. (Mon, 07 Jul 2025 14:19:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 78971 <at> debbugs.gnu.org
Subject: Re: bug#78971: [PATCH] New hook run after saving Rmail MIME
 attachments
Date: Mon, 07 Jul 2025 17:18:33 +0300
> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Date: Mon, 07 Jul 2025 10:16:40 +0200
> 
> This patch adds a hook run after saving attachments in Rmail.  The
> motivation is to be able to perform post-save actions, such as jumping
> to the attachment in Dired.

Hmm... if this is supposed to support user-level features, then using
a hook might not be the best way.  How about offering a user option
for followup actions after saving a MIME attachment?  The value could
be:

  . do nothing (current behavior)
  . visit the file in Emacs
  . visit the file's directory in Dired
  . open the file using a suitable program (using dired-do-open)

I'm not objected to adding a hook, but hooks are mainly for programs,
not for users.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78971; Package emacs. (Mon, 07 Jul 2025 16:08:01 GMT) Full text and rfc822 format available.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78971 <at> debbugs.gnu.org
Subject: Re: bug#78971: [PATCH] New hook run after saving Rmail MIME
 attachments
Date: Mon, 07 Jul 2025 18:07:46 +0200
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "Paul D. Nelson" <ultrono <at> gmail.com>
>> Date: Mon, 07 Jul 2025 10:16:40 +0200
>> 
>> This patch adds a hook run after saving attachments in Rmail.  The
>> motivation is to be able to perform post-save actions, such as jumping
>> to the attachment in Dired.
>
> Hmm... if this is supposed to support user-level features, then using
> a hook might not be the best way.  How about offering a user option
> for followup actions after saving a MIME attachment?  The value could
> be:
>
>   . do nothing (current behavior)
>   . visit the file in Emacs
>   . visit the file's directory in Dired
>   . open the file using a suitable program (using dired-do-open)
>
> I'm not objected to adding a hook, but hooks are mainly for programs,
> not for users.

Thanks, makes sense.  How about something like the attached?  I retained
a "custom function" option to allow more complicated actions, like
"visiting the file's directory in Dired but only when there's a prefix
arg".

[0001-Add-post-save-actions-for-Rmail-attachments.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78971; Package emacs. (Mon, 07 Jul 2025 16:14:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 78971 <at> debbugs.gnu.org
Subject: Re: bug#78971: [PATCH] New hook run after saving Rmail MIME
 attachments
Date: Mon, 07 Jul 2025 19:12:24 +0300
> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 78971 <at> debbugs.gnu.org
> Date: Mon, 07 Jul 2025 18:07:46 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> >> Date: Mon, 07 Jul 2025 10:16:40 +0200
> >> 
> >> This patch adds a hook run after saving attachments in Rmail.  The
> >> motivation is to be able to perform post-save actions, such as jumping
> >> to the attachment in Dired.
> >
> > Hmm... if this is supposed to support user-level features, then using
> > a hook might not be the best way.  How about offering a user option
> > for followup actions after saving a MIME attachment?  The value could
> > be:
> >
> >   . do nothing (current behavior)
> >   . visit the file in Emacs
> >   . visit the file's directory in Dired
> >   . open the file using a suitable program (using dired-do-open)
> >
> > I'm not objected to adding a hook, but hooks are mainly for programs,
> > not for users.
> 
> Thanks, makes sense.  How about something like the attached?  I retained
> a "custom function" option to allow more complicated actions, like
> "visiting the file's directory in Dired but only when there's a prefix
> arg".

Looks good, thanks.  Let's wait for a few days to let others chime in
and comment.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78971; Package emacs. (Mon, 07 Jul 2025 16:22:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ultrono <at> gmail.com
Cc: 78971 <at> debbugs.gnu.org
Subject: Re: bug#78971: [PATCH] New hook run after saving Rmail MIME
 attachments
Date: Mon, 07 Jul 2025 19:21:30 +0300
> Cc: 78971 <at> debbugs.gnu.org
> Date: Mon, 07 Jul 2025 19:12:24 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Thanks, makes sense.  How about something like the attached?  I retained
> > a "custom function" option to allow more complicated actions, like
> > "visiting the file's directory in Dired but only when there's a prefix
> > arg".
> 
> Looks good, thanks.  Let's wait for a few days to let others chime in
> and comment.

Actually, I do have one aspect we should discuss, I think.
Automatically visiting saved attachments, let alone opening them with
some application, can be dangerous, since these attachments come from
sources that are not necessarily benign or trusted.  So should we
perhaps ask the user for confirmation before acting on the saved file?
Probably also mention this aspect in the doc string of the new user
option?  WDYT?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78971; Package emacs. (Mon, 07 Jul 2025 21:49:02 GMT) Full text and rfc822 format available.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78971 <at> debbugs.gnu.org
Subject: Re: bug#78971: [PATCH] New hook run after saving Rmail MIME
 attachments
Date: Mon, 07 Jul 2025 23:48:49 +0200
> Actually, I do have one aspect we should discuss, I think.
> Automatically visiting saved attachments, let alone opening them with
> some application, can be dangerous, since these attachments come from
> sources that are not necessarily benign or trusted.  So should we
> perhaps ask the user for confirmation before acting on the saved file?
> Probably also mention this aspect in the doc string of the new user
> option?  WDYT?

I think it makes sense to mention this in the doc string and manual, and
to wrap "visit-file" and "open-external" with y-or-n-p -- if not as a
security nag, then to give a way to apply those actions selectively.

On second thought, I'd personally prefer to delete those actions
altogether, and instead, mention in the manual that "visit-directory"
can be followed by the Dired keystrokes "RET" or "E" to achieve the
other actions.  The extra keystrokes serve as implicit confirmation, but
without the fatigue from repetitive y-or-n-p.

On the other hand, I understand if you or others think this approach
would be less user-friendly than giving direct "visit-file" and
"open-external" options.  Digging around a bit, a further option to
consider would be "view-with-mailcap", calling (mailcap-view-file
filename) wrapped with y-or-n-p.




This bug report was last modified today.

Previous Next


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