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