From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 39543@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 [thread overview]
Message-ID: <87h7zl8bkb.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87r1yp5s03.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 20 Feb 2020 14:05:00 +0100")
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
next prev parent reply other threads:[~2020-02-20 16:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-10 13:19 bug#39543: 28.0.50; Add completion to gnus-summary-save-parts from mime parts in the message Filipp Gunbin
2020-02-10 19:29 ` Eric Abrahamsen
2020-02-20 13:05 ` Lars Ingebrigtsen
2020-02-20 16:31 ` Eric Abrahamsen [this message]
2020-02-20 17:45 ` Lars Ingebrigtsen
2020-03-12 19:22 ` Eric Abrahamsen
2020-07-19 14:16 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7zl8bkb.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=39543@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.