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

Previous Next

Full log

View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39543 <at> debbugs.gnu.org
Subject: 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

Previous Next

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