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

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

[Filipp Gunbin]

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

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

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

Filipp Gunbin <fgunbin@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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnus-save-mime-completion.diff --]
[-- Type: text/x-patch, Size: 960 bytes --]

diff --git a/lisp/gnus/gnus-sum.el b/lisp/gnus/gnus-sum.el
index a47e657623..39d9ad5057 100644
--- a/lisp/gnus/gnus-sum.el
+++ b/lisp/gnus/gnus-sum.el
@@ -12508,10 +12508,12 @@ gnus-summary-save-parts
   "Save parts matching TYPE to DIR.
 If REVERSE, save parts that do not match TYPE."
   (interactive
-   (list (read-string "Save parts of type: "
-		      (or (car gnus-summary-save-parts-type-history)
-			  gnus-summary-save-parts-default-mime)
-		      'gnus-summary-save-parts-type-history)
+   (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)
 	 (setq gnus-summary-save-parts-last-directory
 	       (read-directory-name "Save to directory: "
                                     gnus-summary-save-parts-last-directory

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@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

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

[Eric Abrahamsen]

On 02/20/20 14:05 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@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

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@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

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

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@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

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@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