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