Re: yank-media: allow users to limit image types that can be inserted

[Visuwesh <visuweshm@gmail.com>]

[-- 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.