GNU bug report logs - #36864
hitting r deletes attachment rather than replying

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36864 in the body.
You can then email your comments to 36864 AT debbugs.gnu.org in the normal way.

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

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

From: Par Kurlberg <kurlberg <at> math.kth.se>
To: submit <at> debbugs.gnu.org (The Gnus Bugfixing Girls + Boys)
Subject: hitting r deletes attachment rather than replying
Date: Wed, 31 Jul 2019 01:22:56 +0200

Hi,

I've been bit by the following a couple of times: I read a message with
an attachment, then look at the attachment (say by placing the cursor
over it and hitting RET or similar), and then want to reply to the
message by hitting r (which usually sets up a buffer for writing a
reply).  However, when the cursor is on the attachment button this
invokes gnus-mime-replace-part with the result of the attachment
effectively being deleted.  (Supposedly it is saved somewhere on disk
but this does not seem to work.)  In any case, even if saved somewhere
I'm not sure that the "lost" attachment can be reattached into the
message.  (I have looked but not found a way to undo
gnus-mime-replace-part, perhaps I missed some easy solution here?)

Bug report/feature request: could you *PLEASE* have "r" asking for
confirmation?  Meanwhile I'll try to figure out how rebind "r" or just
redefine gnus-mime-replace-part in my config. :-)

Best,
Pär 




Gnus v5.13
GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-09-20 on lcy01-07, modified by Debian

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Par Kurlberg <kurlberg <at> math.kth.se>
Cc: 36864 <at> debbugs.gnu.org
Subject: Re: bug#36864: hitting r deletes attachment rather than replying
Date: Fri, 23 Aug 2019 07:03:29 +0200

Par Kurlberg <kurlberg <at> math.kth.se> writes:

> I've been bit by the following a couple of times: I read a message with
> an attachment, then look at the attachment (say by placing the cursor
> over it and hitting RET or similar), and then want to reply to the
> message by hitting r (which usually sets up a buffer for writing a
> reply).  However, when the cursor is on the attachment button this
> invokes gnus-mime-replace-part with the result of the attachment
> effectively being deleted.  (Supposedly it is saved somewhere on disk
> but this does not seem to work.)  In any case, even if saved somewhere
> I'm not sure that the "lost" attachment can be reattached into the
> message.  (I have looked but not found a way to undo
> gnus-mime-replace-part, perhaps I missed some easy solution here?)
>
> Bug report/feature request: could you *PLEASE* have "r" asking for
> confirmation?  Meanwhile I'll try to figure out how rebind "r" or just
> redefine gnus-mime-replace-part in my config. :-)

The command does prompt you for a file name to replace the MIME part
with, so I don't think asking for another confirmation will make much
difference.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Par Kurlberg <kurlberg <at> math.kth.se>
Cc: 36864 <at> debbugs.gnu.org
Subject: Re: bug#36864: hitting r deletes attachment rather than replying
Date: Sun, 25 Aug 2019 07:58:48 +0200

Par Kurlberg <kurlberg <at> math.kth.se> writes:

> I have the habit of quickly hitting return right after hitting r (in
> order to make a blank line at the top of the reply message).  The
> minibuffer, after hitting r, contains a string with the current
> directory in order to start a prompt for the file name to save the
> attachment in.  If you hit return then, the attachment is gone and
> what's worse: there is no file in the selected directory - i.e., the
> attachment does not seem to be saved at all.  (I might be looking in the
> wrong place but it's not clear at all if/where the attachment is indeed
> saved.)

Ah, yes the command should check whether the file exists before removing
the MIME part and substituting with nothing.

This has now been fixed on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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