emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Visuwesh
Subject: Re: yank-media: allow users to limit image types that can be inserted
Date: Tue, 29 Oct 2024 16:59:34 +0530
User-agent: Gnus/5.13 (Gnus v5.13)

[ஞாயிறு அக்டோபர் 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.

Attachment: yank-media-filter.patch
Description: Text Data

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]