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: Tue, 29 Oct 2024 16:59:34 +0530
> 
> > 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.

This (and the patch you suggest) completes the full circle of this
discussion: it started when I said that such a global preference makes
very little sense to me, based on my experience with yanking different
data types in other applications.  Users have no reason for such
preferences, as they almost never have enough reasons to prefer one
type over the others _globally_.  The preference only makes sense in
each specific case, and then asking the user to choose is exactly TRT,
which we already do.

> >> 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 might, though.  And it already does, in fact: the few modes which
support yank-media only register some of the handlers, but not others.
Did you ask yourself why message.el registers only the handler for
images, but not, say, for text/html?  A major mode which doesn't
support embedded images will probably refrain from installing image/*
handlers, etc.

> It simply wants to respect the "soft" preferences of the user.

If we think such global preferences might make sense, we need to
describe and discuss the use cases and reasons for having such
preferences.  Until now, the only reason I've heard was the desire to
save some typing, i.e. let Emacs yank the one "preferred" media type
without asking.  If that is the reason, we could have instead a
feature whereby "the best" or "the most appropriate" media type is
yanked without asking; for example if yank-media is invoked with a
prefix argument.  (Or maybe the other way around: without the argument
yank-media would yank "the best" media type.)  This is what many other
applications do, except that they do it when you type Ctrl-V, whereas
we decided, and for good reasons, not to change how C-y work (though I
don't see why some optional feature could not make C-y call
yank-media).

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

Major mode _does_ have a part: it registers only the handlers it wants
to support.  So it determines, up front, which media types will be
available, even if more of them are in the clipboard.

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

Please tell me why on earth would you prefer PNG to JPEG when yanking,
or vice versa.  The result is an image displayed in the buffer, which
is neither PNG nor JPEG.  Why does it matter _for_you_personally_
which intermediate format will Emacs use as part of the yanking
process?

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

If we want to avoid the question when several image formats are
available, we could teach Org, or Emacs in general, which formats to
prefer.  For example, JPEG is generally inferior because it's lossy,
so we could have that hypothetical variant of yank-media which doesn't
ask questions to always prefer PNG to JPEG if both are possible.  This
is IMO better than asking the users to decide that for Emacs.

Anyway, since with this message we've made a full circle, let me
summarize my opinions on this:

  . I think we should add to Emacs rules for preferring one media
    format over the others when several are available and supported
  . Such rules should be customized by major modes based on their
    features and preferences (e.g., a mode that has no support for
    faces might prefer plain text to other textual formats)
  . I think we should have a variant of yank-media that yanks "the
    best" of the available formats without asking, based on the above
    rules

If after all of this people still want a global "preference", I won't
mount the barricades to fight that, although, as I explained, such a
global preference makes little sense to me, and sounds like an
inferior replacement for the missing built-in preference rules I think
we should have.