[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39543: 28.0.50; Add completion to gnus-summary-save-parts from mime
bug#39543: 28.0.50; Add completion to gnus-summary-save-parts from mime parts in the message
Thu, 20 Feb 2020 14:05:00 +0100
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Eric Abrahamsen <address@hidden> 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
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