GNU bug report logs - #39543
28.0.50; Add completion to gnus-summary-save-parts from mime parts in the message

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 39543 in the body.
You can then email your comments to 39543 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: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Add completion to gnus-summary-save-parts from mime parts
 in the message
Date: Mon, 10 Feb 2020 16:19:13 +0300

As gnus-summary-save-parts (X m) is invoked on the article, it could
offer completion based on what mime parts are present in the article.

Thanks.

In GNU Emacs 28.0.50 (build 22, x86_64-apple-darwin19.2.0, NS appkit-1894.20 Version 10.15.2 (Build 19C57))
 of 2020-02-07 built on fgunbin.local
Repository revision: 30abcda54e1b0e15fc10b3db1c2b9f89ca521bfa
Repository branch: master
System Description:  Mac OS X 10.15.2

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#39543: 28.0.50; Add completion to gnus-summary-save-parts
 from mime parts in the message
Date: Mon, 10 Feb 2020 11:29:23 -0800

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

Filipp Gunbin <fgunbin <at> fastmail.fm> writes:

> As gnus-summary-save-parts (X m) is invoked on the article, it could
> offer completion based on what mime parts are present in the article.

I've attached a "dumb" version of what that could look like.

Two notes:

1. This would obsolete `gnus-summary-save-parts-default-mime'.
   Personally I think that's totally fine: between completion and
   a history variable, I don't see any use for a default
   value.
2. If we go this route, it would be nice to extend it so that, for
   instance, if _any_ image/ media types are present, we also manually
   add a "image/*" entry to the completion collection. Or for maximum
   OCD, only add that "image/*" entry if there are more than one image/
   type handles present. Matches are not required, so you could always
   just type in your own regexp, anyway.

Let's see if anyone has any comments.

[gnus-save-mime-completion.diff (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 39543 <at> debbugs.gnu.org
Subject: Re: bug#39543: 28.0.50; Add completion to gnus-summary-save-parts
 from mime parts in the message
Date: Thu, 20 Feb 2020 14:05:00 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

>> As gnus-summary-save-parts (X m) is invoked on the article, it could
>> offer completion based on what mime parts are present in the article.

Sounds like a good idea, but is probably not practical, since it would
mean that Gnus would have to retrieve all the process-marked articles
first to do the prompting.  If there's only a single article in the
list, then it would be fine.

> I've attached a "dumb" version of what that could look like.
>
> Two notes:
>
> 1. This would obsolete `gnus-summary-save-parts-default-mime'.
>    Personally I think that's totally fine: between completion and
>    a history variable, I don't see any use for a default
>    value.

I think that variable is useful.  In practice, people are interested in
saving only certain types (images for some, pdfs for others), and being
able to hit RET to do just that is nice.  This is particularly the case
when using the command over a large set of messages (typically, all the
messages in the summary buffer).

> 2. If we go this route, it would be nice to extend it so that, for
>    instance, if _any_ image/ media types are present, we also manually
>    add a "image/*" entry to the completion collection. Or for maximum
>    OCD, only add that "image/*" entry if there are more than one image/
>    type handles present. Matches are not required, so you could always
>    just type in your own regexp, anyway.

Adding foo/* variants if several different foo/s are in there would be nice.

> +   (list (completing-read "Save parts of type: "
> +			  (gnus-eval-in-buffer-window gnus-article-buffer
> +			    (delete-dups
> +			     (mapcar (lambda (h) (mm-handle-media-type (cdr h)))
> +				     gnus-article-mime-handle-alist)))
> +			  nil nil nil 'gnus-summary-save-parts-type-history)

This only deals with types in the current article?  The message may not
even be selected, so (in addition to not working on sets of articles),
it would not work if the user hasn't selected an article?

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

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39543 <at> debbugs.gnu.org
Subject: Re: bug#39543: 28.0.50; Add completion to gnus-summary-save-parts
 from mime parts in the message
Date: Thu, 20 Feb 2020 08:31:48 -0800

On 02/20/20 14:05 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>>> As gnus-summary-save-parts (X m) is invoked on the article, it could
>>> offer completion based on what mime parts are present in the article.
>
> Sounds like a good idea, but is probably not practical, since it would
> mean that Gnus would have to retrieve all the process-marked articles
> first to do the prompting.  If there's only a single article in the
> list, then it would be fine.

Well I did say it was a "dumb" version :)

I hadn't considered the case of multiple articles. Just for the sake of
argument: if we're expecting to save parts from some of the
process-marked articles, aren't we going to need to fetch them all,
anyway?

>> I've attached a "dumb" version of what that could look like.
>>
>> Two notes:
>>
>> 1. This would obsolete `gnus-summary-save-parts-default-mime'.
>>    Personally I think that's totally fine: between completion and
>>    a history variable, I don't see any use for a default
>>    value.
>
> I think that variable is useful.  In practice, people are interested in
> saving only certain types (images for some, pdfs for others), and being
> able to hit RET to do just that is nice.  This is particularly the case
> when using the command over a large set of messages (typically, all the
> messages in the summary buffer).

I still think that combining "the mimetype we saved last time" with
"what's actually present and saveable" mostly obviates any generally
preferred mimetype. But I don't feel strongly about this at all, and
there's no great need to remove that variable.

>> 2. If we go this route, it would be nice to extend it so that, for
>>    instance, if _any_ image/ media types are present, we also manually
>>    add a "image/*" entry to the completion collection. Or for maximum
>>    OCD, only add that "image/*" entry if there are more than one image/
>>    type handles present. Matches are not required, so you could always
>>    just type in your own regexp, anyway.
>
> Adding foo/* variants if several different foo/s are in there would be nice.
>
>> +   (list (completing-read "Save parts of type: "
>> +			  (gnus-eval-in-buffer-window gnus-article-buffer
>> +			    (delete-dups
>> +			     (mapcar (lambda (h) (mm-handle-media-type (cdr h)))
>> +				     gnus-article-mime-handle-alist)))
>> +			  nil nil nil 'gnus-summary-save-parts-type-history)
>
> This only deals with types in the current article?  The message may not
> even be selected, so (in addition to not working on sets of articles),
> it would not work if the user hasn't selected an article?

Right, like I said this was more a proof of concept than a working
solution. If you think there's a practical improvement to be made in
here, I'd be happy to work on it.

Eric

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 39543 <at> debbugs.gnu.org
Subject: Re: bug#39543: 28.0.50; Add completion to gnus-summary-save-parts
 from mime parts in the message
Date: Thu, 20 Feb 2020 18:45:01 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I hadn't considered the case of multiple articles. Just for the sake of
> argument: if we're expecting to save parts from some of the
> process-marked articles, aren't we going to need to fetch them all,
> anyway?

We are, but unless you have backlog (etc) switched on, Gnus will then
fetch everything twice.

> Right, like I said this was more a proof of concept than a working
> solution. If you think there's a practical improvement to be made in
> here, I'd be happy to work on it.

If there's only one article in the selection, then ensuring that it's
fetched should be sufficient before you look at the MIME handles.

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

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#39543: 28.0.50;
 Add completion to gnus-summary-save-parts from mime parts in the
 message
Date: Thu, 12 Mar 2020 12:22:02 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I hadn't considered the case of multiple articles. Just for the sake of
>> argument: if we're expecting to save parts from some of the
>> process-marked articles, aren't we going to need to fetch them all,
>> anyway?
>
> We are, but unless you have backlog (etc) switched on, Gnus will then
> fetch everything twice.
>
>> Right, like I said this was more a proof of concept than a working
>> solution. If you think there's a practical improvement to be made in
>> here, I'd be happy to work on it.
>
> If there's only one article in the selection, then ensuring that it's
> fetched should be sufficient before you look at the MIME handles.

Bleagh, no time for coding... Anyway, I played with this, and the amount
of (duplicate) code that would be required to check if we're only
dealing with one article, and whether the article is fetched or not,
sort of makes it not quite worth the effort.

Unless we're interested in factoring out the tests in
`gnus-summary-select-article' into a new function like
'gnus-summary-current-article-fetched-p', which could be used in both
places. That might make it easier.

Eric

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 39543 <at> debbugs.gnu.org
Subject: Re: bug#39543: 28.0.50; Add completion to gnus-summary-save-parts
 from mime parts in the message
Date: Sun, 19 Jul 2020 16:16:45 +0200

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Bleagh, no time for coding... Anyway, I played with this, and the amount
> of (duplicate) code that would be required to check if we're only
> dealing with one article, and whether the article is fetched or not,
> sort of makes it not quite worth the effort.

I think so, too.

But offering completion based on just the first article is better than
nothing, so I applied your patch (with some slight changes) to Emacs 28.

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