[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.
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.
- Re: yank-media: allow users to limit image types that can be inserted, Ihor Radchenko, 2024/10/26
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/26
- Re: yank-media: allow users to limit image types that can be inserted, Ihor Radchenko, 2024/10/27
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/27
- Re: yank-media: allow users to limit image types that can be inserted, Visuwesh, 2024/10/27
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/27
- Re: yank-media: allow users to limit image types that can be inserted, Visuwesh, 2024/10/27
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/27
- Re: yank-media: allow users to limit image types that can be inserted, Visuwesh, 2024/10/28
- Re: yank-media: allow users to limit image types that can be inserted,
Visuwesh <=
- Re: yank-media: allow users to limit image types that can be inserted, Pedro, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, pinmacs, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, pinmacs, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/31
- Message not available
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, Ihor Radchenko, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, Eli Zaretskii, 2024/10/31
- Re: yank-media: allow users to limit image types that can be inserted, Ihor Radchenko, 2024/10/31