From: Ihor Radchenko <yantar92@posteo.net>
To: Visuwesh <visuweshm@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
pinmacs@cas.cat, rpluim@gmail.com, 75116@debbugs.gnu.org
Subject: bug#75116: [PATCH] Make 'yank-media' autoselect the best media type
Date: Mon, 06 Jan 2025 18:33:42 +0000 [thread overview]
Message-ID: <87cygzhjw9.fsf@localhost> (raw)
In-Reply-To: <87bjwkbls7.fsf@gmail.com>
Visuwesh <visuweshm@gmail.com> writes:
>>> >> + (setq pref-type (and (null noselect)
>>> >> + (funcall yank-media-autoselect-function
>>> >> + (mapcar #'car all-types))))
>>> >> + (cond
>>> >> + ;; We have one preferred mime type so use it unconditionally.
>>> >> + ((and pref-type (symbolp pref-type))
>>> >> + (funcall (cdr (assq pref-type all-types)) pref-type
>>> >> + (yank-media--get-selection pref-type)))
>>> >> + ;; The user chose to not autoselect and there's just a single type,
>>> >> + ;; just call the handler.
>>> >> + ((and (null pref-type) (length= all-types 1))
>>> >> + (funcall (cdar all-types) (caar all-types)
>>> >> + (yank-media--get-selection (caar all-types))))
>>> >
>>> > This goes against what the doc string says. And I think the doc
>>> > string describes a better behavior: if the user asked not to
>>> > auto-select, we shouldn't, even if there's just one type available.
>>> > We should instead ask the user whether to yank that type, because the
>>> > user could decide she doesn't want that type, even it it's the only
>>> > one.
>>> ...
>>> I want to ensure we are on the same page wrt UI here:
>>>
>>> User asks to autoselect:
>>> 1. autoselect-function (a-s-f) returns one media type: we yank it.
>>
>> Yes.
>>
>>> 2. a-s-f returns multiple media types: we ask the user which one
>>> to yank.
>>
>> No, we use the first one.
>
> Doesn't this mean there is pratically no difference between (1) and (2)?
> Ihor, is this okay? Or did you have something else in mind when you
> asked for the possibility to return multiple types?
Eli, what exactly do you mean by "user asks to autoselect"?
AFAIU, autoselect is done by default. User cannot ask for it. User can
only supply a prefix argument to explicitly disable autoselection.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2025-01-06 18:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-26 12:27 bug#75116: [PATCH] Make 'yank-media' autoselect the best media type Visuwesh
2024-12-26 15:49 ` Eli Zaretskii
2024-12-27 8:58 ` Visuwesh
2024-12-28 12:24 ` Eli Zaretskii
2025-01-06 4:37 ` Visuwesh
2025-01-06 14:10 ` Eli Zaretskii
2025-01-06 18:33 ` Ihor Radchenko [this message]
2025-01-06 18:50 ` Eli Zaretskii
2025-01-06 19:05 ` Ihor Radchenko
2025-01-06 19:15 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cygzhjw9.fsf@localhost \
--to=yantar92@posteo.net \
--cc=75116@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=pinmacs@cas.cat \
--cc=rpluim@gmail.com \
--cc=visuweshm@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).