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

[Eli Zaretskii <eliz@gnu.org>]

> 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?

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

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

> > 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?