From: Visuwesh <visuweshm@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com,
emacs-devel@gnu.org
Subject: Re: yank-media: allow users to limit image types that can be inserted
Date: Tue, 29 Oct 2024 16:59:34 +0530 [thread overview]
Message-ID: <87iktb171d.fsf@gmail.com> (raw)
In-Reply-To: <86iktd8o9h.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Oct 2024 19:11:06 +0200")
[-- Attachment #1: Type: text/plain, Size: 6009 bytes --]
[ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com,
>> emacs-devel@gnu.org
>> Date: Sun, 27 Oct 2024 20:32:21 +0530
>>
>> [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:
>>
>> >> > Examine the available TARGETS, then bind
>> >> > yank-media--registered-handlers to the appropriate value when invoking
>> >> > yank-media.
>> >>
>> >> Would that not defeat the point of yank-media, which is to present a
>> >> simple, common interface to the clipboard data to major-mode authors?
>> >
>> > Which part of the above would "defeat the point of yank-media", and
>> > why?
>>
>> yank-media presents a uniform interface to clipboard data across
>> platforms, in principle. This implies that there is no need to know the
>> ugly details of how the clipboard data is to be fetched, which data
>> types are available and which of them are bogus, etc.
>
> My suggestion does not require any need to know those ugly details.
> It just suggests to remove from the list the handlers a mode doesn't
> want. Removing the, say, image/png handler from the list does not
> require any knowledge how that handler accesses the clipboard nor how
> it extracts PNG images from the clipboard. It just requires to know
> the (trivial) fact that an image/png handler can interpret the
> clipboard data as a PNG image.
>
> So I don't think I understand your reasoning. What did I miss?
That the user does want PNG images is a "soft preference." If the
clipboard only has image/png, the user would have the image/png data
instead of none at all. You offered a solution for this: bind
yank-media--registered-handlers in a custom command but having a
variable would make it easy for the user to have a _global_ preference
across major-modes.
>> The major-mode authors would simply write handlers for all relevant
>> data types and leave it to the user to choose the preferred type if
>> more than one of them is handled by the major-mode.
>
> AFAIU, we were talking about situations where the major mode "knows
> better" than the user, and doesn't want to leave the choice to users.
No, the major-mode does not "know better" than user. It simply wants to
respect the "soft" preferences of the user.
>> But if the major-mode authors have to cater to the user's preferred data
>> types by looking at TARGETS in their "major-mode-yank-media" command,
>> that defeats the abstraction yank-media provides...
>
> I don't understand how. TARGETS include stuff like image/png and
> text/html; how does looking at that defeat any abstractions, and what
> abstractions are those? We cannot consider TARGETS to be an opaque
> object anyway because then we won't be able to ask the user which of
> the MIME types she wants to yank, nor apply any advance preferences of
> the user.
The MIME type the user wants to yank is asked by _yank-media_ currently.
The major-mode has no part in this conversation, and this is exactly
what we want to change.
>> The entire point of using the library, IMHO, is to leave out this
>> nasty business of handling the clipboard to a third party.
>
> What do you mean by "handling the clipboard"? In my mind, "handling
> the clipboard" is what the handlers do, and my suggestion doesn't
> change that, nor does it require any knowledge about their works. It
> only requires to know that each MIME type has a handler, and removing
> that handler from the list will prevent the clipboard data from being
> interpreted as that MIME type.
I admit that my memory failed me when I wrote that. I was under the
impression that yank-media goes through a bit of effort to remove any
nonsensical data types from TARGETS. So, it is not nasty as I initially
meant.
>> > If Org has its own ideas about what's best for the users in some
>> > situations, and if the users agree with that, I don't see what is
>> > wrong with that. The common interface presented by yank-media to
>> > major modes is there so that major modes could use it in whichever
>> > ways they think is best for their users. So I see no problems in
>> > major modes deciding to prefer some handlers over others, not in
>> > principle.
>>
>> We do not disagree about this at all. What we do disagree on is the
>> means by which to achieve this. If we could specify a filter function
>> as a variable that filters out the available data types before
>> presenting it to the user, the major-mode authors would be saved the
>> burden of writing their yank-media-like command which requires the
>> knowledge of obtaining TARGETS and potentially ignoring bogus types in
>> it.
>
> How will that filter function be any different from what I propose?
> You want to filter MIME types, I suggest filtering the handler, but
> since each handler is uniquely identified by the MIME type it handles,
> what exactly is the big difference?
>
> I feel there's some gross misunderstanding here, but what is it?
I hope it is clear now. Two things can be achieved if we add such a
filter function:
1. The user gets to specify her "soft" preference for available MIME
types. This could be done by directly writing such a function
herself or use whatever mechanism the major-mode offers to
enforce this preference. I say "soft" because the user does not
mind to use a "lesser" type if her preferred type is unavailable
which would not be possible by specifically registered only
image/USER-PREFERRED-TYPE.
2. The user gets to specify her preference globally, across
major-modes. This would be hard if major-modes had to write
their own "yank-media" command to cater to the user's
preferences.
The attached patch adds a variable to specify a filter function:
yank-media-preferred-type-function.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: yank-media-filter.patch --]
[-- Type: text/x-diff, Size: 2576 bytes --]
diff --git a/lisp/yank-media.el b/lisp/yank-media.el
index 563aae85419..30ede069769 100644
--- a/lisp/yank-media.el
+++ b/lisp/yank-media.el
@@ -29,6 +29,12 @@
(defvar yank-media--registered-handlers nil)
+(defvar-local yank-media-preferred-type-function nil
+ "Function to select preferred mimetypes out of available ones.
+If non-nil, this function is called with a list of mimetype that is
+handled in the current buffer, and should return a list of preferred
+types to use.")
+
;;;###autoload
(defun yank-media ()
"Yank media (images, HTML and the like) from the clipboard.
@@ -49,18 +55,29 @@ yank-media
(unless all-types
(user-error
"No handler in the current buffer for anything on the clipboard"))
- ;; We have a handler in the current buffer; if there's just
- ;; matching type, just call the handler.
- (if (length= all-types 1)
- (funcall (cdar all-types) (caar all-types)
- (yank-media--get-selection (caar all-types)))
- ;; More than one type the user for what type to insert.
- (let ((type
- (intern
- (completing-read "Several types available, choose one: "
- (mapcar #'car all-types) nil t))))
- (funcall (alist-get type all-types)
- type (yank-media--get-selection type))))))
+ ;; Remove types that are unwanted.
+ (let ((pref-types (funcall (if yank-media-preferred-type-function
+ yank-media-preferred-type-function
+ #'identity)
+ (mapcar #'car all-types))))
+ (unless pref-types
+ (user-error
+ ;; FIXME: Improve the error message.
+ "No handler in the current buffer for preferred data types"))
+ ;; We have a handler in the current buffer; if there's just
+ ;; one preferred type, just call the handler.
+ (if (length= pref-types 1)
+ (let ((data (assq (car pref-types) all-types)))
+ (funcall (cdr data) (car pref-types)
+ (yank-media--get-selection (car pref-types))))
+ ;; More than one type preferred, ask the user for what type to
+ ;; insert.
+ (let ((type
+ (intern
+ (completing-read "Several types available, choose one: "
+ pref-types nil t))))
+ (funcall (alist-get type all-types)
+ type (yank-media--get-selection type)))))))
(defun yank-media--find-matching-media (handled-type)
(seq-filter
[-- Attachment #3: Type: text/plain, Size: 641 bytes --]
Without the patch applied, copying an image from Firefox and using
yank-media in an Org buffer asks me if I want image/png or image/jpeg.
With that patch applied, and after evaluating
(setq-local
yank-media-preferred-type-function
(lambda (types)
(if (memq 'image/png types)
(list 'image/png)
types)))
in an Org buffer, or message-mode buffer, I don't get asked that
question. Afterwards, I copy a JPEG image using xclip then do
yank-media. This yanks the image without asking me anything. This would
not be possible had Org or message-mode only registered a handler for
image/png.
next prev parent reply other threads:[~2024-10-29 11:29 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-22 16:53 yank-media: allow users to limit image types that can be inserted pinmacs
2024-09-23 11:20 ` Eli Zaretskii
2024-09-23 13:46 ` Visuwesh
2024-09-23 14:30 ` Eli Zaretskii
2024-09-23 15:06 ` Visuwesh
2024-09-23 15:48 ` Eli Zaretskii
2024-09-23 15:09 ` Robert Pluim
2024-09-23 15:14 ` Visuwesh
2024-09-23 15:20 ` Robert Pluim
2024-09-23 15:58 ` Eli Zaretskii
2024-09-24 5:00 ` Visuwesh
2024-09-24 5:10 ` Visuwesh
2024-09-24 11:57 ` Eli Zaretskii
2024-09-24 12:42 ` Visuwesh
2024-09-23 15:54 ` Eli Zaretskii
2024-09-23 16:10 ` Robert Pluim
2024-09-23 16:34 ` Eli Zaretskii
2024-09-23 18:00 ` pinmacs
2024-09-23 18:35 ` Eli Zaretskii
2024-09-23 20:45 ` Pedro
2024-09-23 21:08 ` pinmacs
2024-09-24 8:15 ` Robert Pluim
2024-09-24 11:30 ` Eli Zaretskii
2024-09-24 12:18 ` Robert Pluim
2024-09-24 13:08 ` Eli Zaretskii
2024-09-24 13:38 ` Visuwesh
2024-09-24 13:50 ` Eli Zaretskii
2024-09-24 5:08 ` Visuwesh
2024-09-24 12:00 ` Eli Zaretskii
2024-09-24 12:50 ` Visuwesh
2024-09-24 13:23 ` Eli Zaretskii
2024-09-24 13:37 ` Visuwesh
2024-10-26 17:27 ` Ihor Radchenko
2024-10-26 19:09 ` Eli Zaretskii
2024-10-27 8:17 ` Ihor Radchenko
2024-10-27 9:14 ` Eli Zaretskii
2024-10-27 9:36 ` Visuwesh
2024-10-27 10:09 ` Eli Zaretskii
2024-10-27 15:02 ` Visuwesh
2024-10-27 17:11 ` Eli Zaretskii
2024-10-28 13:37 ` Visuwesh
2024-10-29 11:29 ` Visuwesh [this message]
2024-10-28 18:39 ` Ihor Radchenko
2024-10-28 18:50 ` Eli Zaretskii
2024-09-23 18:11 ` Eli Zaretskii
2024-09-24 8:38 ` Robert Pluim
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=87iktb171d.fsf@gmail.com \
--to=visuweshm@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=pinmacs@cas.cat \
--cc=rpluim@gmail.com \
--cc=yantar92@posteo.net \
/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).