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

[Pedro <pedro@cas.cat>]

[-- Attachment #1.1.1: Type: text/plain, Size: 8680 bytes --]

Hi Visuwesh,

Thanks for the patch!! It is very useful to me.

I tested it and it works as I originally expected: reduce the 
interaction to minimum: I don't need to press enter anymore! :)

I also tested it with two types [1]: jpeg and png; and then you see a 
selector with just the two types you care instead of the 7 types that 
flameshot screen capture tool offers.

The approach of this patch permits to have different yank commands with 
different keybindings and context to respond to different needs (For the 
things I care, I end up having two commands, one that is simple and fast 
with the most preferred thing; and the other that gives all flexibility 
and possibilities). So, happy to see flexibility here too.

I would like to know if it can be included upstream as it is or what 
else needs to be done or discussed.

Meanwhile I will add it to my config.

It might be useful to know why this is better: it is less error prone to 
what I have now. Let me explain this: the other day, by mistake (being 
in a hurry) I did several screen captures and I thought I was using .png 
(I usually pick png on the first time, and then, by frequency, it 
appears in the first position because of the completion tool 
(vertico/orderless ?)). But I was wrong, I took .pbm, for that case, 
that was fine, it was notes for me, but it could be the case of having 
screen captures with the wrong format and having difficulty to generate 
them again. This patch and approach helps the user to avoid that risk.

Cheers,
pinmacs

[1]
   (setq-local
     yank-media-preferred-type-function
     (lambda (types)
       (if (or
            (memq 'image/png types)
            (memq 'image/jpeg types))
           (list 'image/png 'image/jpeg)
         types)))


On 2024-10-29 12:29, Visuwesh wrote:
> [ஞாயிறு அக்டோபர் 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.
>
>
> 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.
>


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3323 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]