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

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

[pinmacs]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

Hi,

I submitted the following Feature Request in the orgmode list [1]. They 
said that the second part related to "limitting image types that can be 
inserted" should be done in the core emacs side.

In that same thread [1], Ihor proposed different ways to implement it 
[2], I also took how it explained the feature as part of this email-subject.

The thing is that with orgmode we can easily attach images to buffer 
thanks to `yank-media' feature, but there is a dialogue we cannot skip 
and that is: selecting image types. Find attached an image file 
"selecting-image-types.png", where you can see the 7 candidates for a 
screenshot I did to serve as an example.

1. In case I want to be fast, I would like to skip that dialog entirely 
and just use the image/png variant.
2. In another perspective, I would consider that the relevant decision 
for a screenshot would be between two of them: image/png and image/jpeg
3. Another user could argue why the other 5 types are interesting in 
general or for their particular use case...

... but let's stop that discussion here. Looks like filtering image 
types would be a useful customization for the users. If done as a 
variable, in certain cases, that could be local binded and specific to 
some fast function that immediately inserts an image, and in another 
case, the global var would select only those image types relevant for 
that particular user.

That is also positive if users want to add even more image types, with a 
good and reasonable default, users will not worry about too many options 
at some point.

Thanks for your attention,
pinmacs

[1] https://mail.gnu.org/archive/html/emacs-orgmode/2024-09/msg00209.html

[2] https://mail.gnu.org/archive/html/emacs-orgmode/2024-09/msg00266.html

[-- Attachment #2: selecting-image-types.png --]
[-- Type: image/png, Size: 10807 bytes --]

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

[Eli Zaretskii]

> Date: Sun, 22 Sep 2024 13:53:06 -0300
> From: pinmacs <pinmacs@cas.cat>
> 
> I submitted the following Feature Request in the orgmode list [1]. They 
> said that the second part related to "limitting image types that can be 
> inserted" should be done in the core emacs side.
> 
> In that same thread [1], Ihor proposed different ways to implement it 
> [2], I also took how it explained the feature as part of this email-subject.
> 
> The thing is that with orgmode we can easily attach images to buffer 
> thanks to `yank-media' feature, but there is a dialogue we cannot skip 
> and that is: selecting image types. Find attached an image file 
> "selecting-image-types.png", where you can see the 7 candidates for a 
> screenshot I did to serve as an example.
> 
> 1. In case I want to be fast, I would like to skip that dialog entirely 
> and just use the image/png variant.
> 2. In another perspective, I would consider that the relevant decision 
> for a screenshot would be between two of them: image/png and image/jpeg
> 3. Another user could argue why the other 5 types are interesting in 
> general or for their particular use case...
> 
> ... but let's stop that discussion here. Looks like filtering image 
> types would be a useful customization for the users. If done as a 
> variable, in certain cases, that could be local binded and specific to 
> some fast function that immediately inserts an image, and in another 
> case, the global var would select only those image types relevant for 
> that particular user.
> 
> That is also positive if users want to add even more image types, with a 
> good and reasonable default, users will not worry about too many options 
> at some point.

Isn't this already possible by using yank-media-handler to register
only the handlers the Lisp program wants to handle?  If that doesn't
fit the bill, please explain why.

Thanks.

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

[Visuwesh]

[திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:

>> Date: Sun, 22 Sep 2024 13:53:06 -0300
>> From: pinmacs <pinmacs@cas.cat>
>> 
>> I submitted the following Feature Request in the orgmode list [1]. They 
>> said that the second part related to "limitting image types that can be 
>> inserted" should be done in the core emacs side.
>> 
>> In that same thread [1], Ihor proposed different ways to implement it 
>> [2], I also took how it explained the feature as part of this email-subject.
>> 
>> The thing is that with orgmode we can easily attach images to buffer 
>> thanks to `yank-media' feature, but there is a dialogue we cannot skip 
>> and that is: selecting image types. Find attached an image file 
>> "selecting-image-types.png", where you can see the 7 candidates for a 
>> screenshot I did to serve as an example.
>> 
>> 1. In case I want to be fast, I would like to skip that dialog entirely 
>> and just use the image/png variant.
>> 2. In another perspective, I would consider that the relevant decision 
>> for a screenshot would be between two of them: image/png and image/jpeg
>> 3. Another user could argue why the other 5 types are interesting in 
>> general or for their particular use case...
>> 
>> ... but let's stop that discussion here. Looks like filtering image 
>> types would be a useful customization for the users. If done as a 
>> variable, in certain cases, that could be local binded and specific to 
>> some fast function that immediately inserts an image, and in another 
>> case, the global var would select only those image types relevant for 
>> that particular user.
>> 
>> That is also positive if users want to add even more image types, with a 
>> good and reasonable default, users will not worry about too many options 
>> at some point.
>
> Isn't this already possible by using yank-media-handler to register
> only the handlers the Lisp program wants to handle?  If that doesn't
> fit the bill, please explain why.

When you copy an image in Firefox, it puts both image/png and image/jpeg
in the clipboard.  The Lisp program could register a handle for
image/png but if the non-Emacs program puts only, say, image/jpeg then
we wouldn't be able to handle the image anymore.  For the most part, the
Lisp program wouldn't care about the specific format of the image but
the fact that it is an image.  An user option that would tell the
preferred type in the presence of _multiple_ matches for the handler's
regexp would be nice to have.

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: pinmacs <pinmacs@cas.cat>,  emacs-devel@gnu.org
> Date: Mon, 23 Sep 2024 19:16:23 +0530
> 
> [திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:
> 
> > Isn't this already possible by using yank-media-handler to register
> > only the handlers the Lisp program wants to handle?  If that doesn't
> > fit the bill, please explain why.
> 
> When you copy an image in Firefox, it puts both image/png and image/jpeg
> in the clipboard.  The Lisp program could register a handle for
> image/png but if the non-Emacs program puts only, say, image/jpeg then
> we wouldn't be able to handle the image anymore.  For the most part, the
> Lisp program wouldn't care about the specific format of the image but
> the fact that it is an image.  An user option that would tell the
> preferred type in the presence of _multiple_ matches for the handler's
> regexp would be nice to have.

IMO, for users we already have what is needed: when we detect several
formats, we show them to the user and ask him/her to tell us which
format he/she wants to use.

The issue at hand here, AFAIU, is not the UI, but how Lisp programs
(and Org in particular) can control this.  If the issue is the user
interface, then I honestly don't understand what issue is being
brought up, because in that case we already have the correct and
comprehensive solution, similar to what other advanced apps do in
these cases.

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

[Visuwesh]

[திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: pinmacs <pinmacs@cas.cat>,  emacs-devel@gnu.org
>> Date: Mon, 23 Sep 2024 19:16:23 +0530
>> 
>> [திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:
>> 
>> > Isn't this already possible by using yank-media-handler to register
>> > only the handlers the Lisp program wants to handle?  If that doesn't
>> > fit the bill, please explain why.
>> 
>> When you copy an image in Firefox, it puts both image/png and image/jpeg
>> in the clipboard.  The Lisp program could register a handle for
>> image/png but if the non-Emacs program puts only, say, image/jpeg then
>> we wouldn't be able to handle the image anymore.  For the most part, the
>> Lisp program wouldn't care about the specific format of the image but
>> the fact that it is an image.  An user option that would tell the
>> preferred type in the presence of _multiple_ matches for the handler's
>> regexp would be nice to have.
>
> IMO, for users we already have what is needed: when we detect several
> formats, we show them to the user and ask him/her to tell us which
> format he/she wants to use.

[ IMO also, the current interface is fine.  ]

> The issue at hand here, AFAIU, is not the UI, but how Lisp programs
> (and Org in particular) can control this.  If the issue is the user
> interface, then I honestly don't understand what issue is being
> brought up, because in that case we already have the correct and
> comprehensive solution, similar to what other advanced apps do in
> these cases.

AFAIK, the OP wants to skip Emacs asking for the preferred format and
instead let her choose a specific format if already present.  The goal
here is to keep the chit-chat with Emacs to a minimum which I understand
since I initially wrote the yank-media code for Org to keep manual
intervention to a minimum when linking to images, etc.

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: pinmacs@cas.cat,  emacs-devel@gnu.org
> Date: Mon, 23 Sep 2024 20:36:42 +0530
> 
> [திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:
> 
> > The issue at hand here, AFAIU, is not the UI, but how Lisp programs
> > (and Org in particular) can control this.  If the issue is the user
> > interface, then I honestly don't understand what issue is being
> > brought up, because in that case we already have the correct and
> > comprehensive solution, similar to what other advanced apps do in
> > these cases.
> 
> AFAIK, the OP wants to skip Emacs asking for the preferred format and
> instead let her choose a specific format if already present.  The goal
> here is to keep the chit-chat with Emacs to a minimum which I understand
> since I initially wrote the yank-media code for Org to keep manual
> intervention to a minimum when linking to images, etc.

I don't understand how can this work in principle, given the number of
possibilities.  It is not an incident that other applications that
support similar functionality provide only 2 possibilities: either
type the equivalent of C-y and get the format that the application
decided you want, or select from the list of possible formats.

I'm all ears to hear what other UIs could be useful in this case.

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

[Robert Pluim]

>>>>> On Mon, 23 Sep 2024 17:30:53 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Visuwesh <visuweshm@gmail.com>
    >> Cc: pinmacs <pinmacs@cas.cat>,  emacs-devel@gnu.org
    >> Date: Mon, 23 Sep 2024 19:16:23 +0530
    >> 
    >> [திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:
    >> 
    >> > Isn't this already possible by using yank-media-handler to register
    >> > only the handlers the Lisp program wants to handle?  If that doesn't
    >> > fit the bill, please explain why.
    >> 
    >> When you copy an image in Firefox, it puts both image/png and image/jpeg
    >> in the clipboard.  The Lisp program could register a handle for
    >> image/png but if the non-Emacs program puts only, say, image/jpeg then
    >> we wouldn't be able to handle the image anymore.  For the most part, the
    >> Lisp program wouldn't care about the specific format of the image but
    >> the fact that it is an image.  An user option that would tell the
    >> preferred type in the presence of _multiple_ matches for the handler's
    >> regexp would be nice to have.

    Eli> IMO, for users we already have what is needed: when we detect several
    Eli> formats, we show them to the user and ask him/her to tell us which
    Eli> format he/she wants to use.

But that requires user interaction. I think the original request could
be summed up as "if the list contains image/png, donʼt ask me, just
insert the image".

    Eli> The issue at hand here, AFAIU, is not the UI, but how Lisp programs
    Eli> (and Org in particular) can control this.  If the issue is the user
    Eli> interface, then I honestly don't understand what issue is being
    Eli> brought up, because in that case we already have the correct and
    Eli> comprehensive solution, similar to what other advanced apps do in
    Eli> these cases.

You have to register the yank-media-handler before the yank-media
call, so org canʼt control this: it has to register for "image/.*"
because it canʼt know what formats will be presented to it. I guess it
could have a user option to filter the results from inside its
yank-media-handler, but then *every* package that wants to support
image yanking will have to implement something similar: we should just
implement such handling in the yank-media code.

Robert
-- 

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

[Visuwesh]

[திங்கள் செப்டம்பர் 23, 2024] Robert Pluim wrote:


>     Eli> The issue at hand here, AFAIU, is not the UI, but how Lisp programs
>     Eli> (and Org in particular) can control this.  If the issue is the user
>     Eli> interface, then I honestly don't understand what issue is being
>     Eli> brought up, because in that case we already have the correct and
>     Eli> comprehensive solution, similar to what other advanced apps do in
>     Eli> these cases.
>
> You have to register the yank-media-handler before the yank-media
> call, so org canʼt control this: it has to register for "image/.*"
> because it canʼt know what formats will be presented to it. I guess it
> could have a user option to filter the results from inside its
> yank-media-handler, but then *every* package that wants to support
> image yanking will have to implement something similar: we should just
> implement such handling in the yank-media code.

AFAIR the yank-media code, there's no way for the handlers to reject a
specific format.  yank-media, the command, asks the user the type she
wants, _then_ calls the handler specific to that type.  The handler
cannot influence anything during this interaction.

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

[Robert Pluim]

>>>>> On Mon, 23 Sep 2024 20:44:19 +0530, Visuwesh <visuweshm@gmail.com> said:

    Visuwesh> [திங்கள் செப்டம்பர் 23, 2024] Robert Pluim wrote:
    Eli> The issue at hand here, AFAIU, is not the UI, but how Lisp programs
    Eli> (and Org in particular) can control this.  If the issue is the user
    Eli> interface, then I honestly don't understand what issue is being
    Eli> brought up, because in that case we already have the correct and
    Eli> comprehensive solution, similar to what other advanced apps do in
    Eli> these cases.
    >> 
    >> You have to register the yank-media-handler before the yank-media
    >> call, so org canʼt control this: it has to register for "image/.*"
    >> because it canʼt know what formats will be presented to it. I guess it
    >> could have a user option to filter the results from inside its
    >> yank-media-handler, but then *every* package that wants to support
    >> image yanking will have to implement something similar: we should just
    >> implement such handling in the yank-media code.

    Visuwesh> AFAIR the yank-media code, there's no way for the handlers to reject a
    Visuwesh> specific format.  yank-media, the command, asks the user the type she
    Visuwesh> wants, _then_ calls the handler specific to that type.  The handler
    Visuwesh> cannot influence anything during this interaction.

Youʼre right. So even more reason to put such filtering in the
yank-media code.

Robert
-- 

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  pinmacs@cas.cat,  emacs-devel@gnu.org
> Date: Mon, 23 Sep 2024 20:44:19 +0530
> 
> [திங்கள் செப்டம்பர் 23, 2024] Robert Pluim wrote:
> 
> 
> >     Eli> The issue at hand here, AFAIU, is not the UI, but how Lisp programs
> >     Eli> (and Org in particular) can control this.  If the issue is the user
> >     Eli> interface, then I honestly don't understand what issue is being
> >     Eli> brought up, because in that case we already have the correct and
> >     Eli> comprehensive solution, similar to what other advanced apps do in
> >     Eli> these cases.
> >
> > You have to register the yank-media-handler before the yank-media
> > call, so org canʼt control this: it has to register for "image/.*"
> > because it canʼt know what formats will be presented to it. I guess it
> > could have a user option to filter the results from inside its
> > yank-media-handler, but then *every* package that wants to support
> > image yanking will have to implement something similar: we should just
> > implement such handling in the yank-media code.
> 
> AFAIR the yank-media code, there's no way for the handlers to reject a
> specific format.  yank-media, the command, asks the user the type she
> wants, _then_ calls the handler specific to that type.  The handler
> cannot influence anything during this interaction.

This is true, but I don't see how it is relevant to what I suggested.

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

[Visuwesh]

[திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  pinmacs@cas.cat,  emacs-devel@gnu.org
>> Date: Mon, 23 Sep 2024 20:44:19 +0530
>> 
>> [திங்கள் செப்டம்பர் 23, 2024] Robert Pluim wrote:
>> 
>> 
>> >     Eli> The issue at hand here, AFAIU, is not the UI, but how Lisp programs
>> >     Eli> (and Org in particular) can control this.  If the issue is the user
>> >     Eli> interface, then I honestly don't understand what issue is being
>> >     Eli> brought up, because in that case we already have the correct and
>> >     Eli> comprehensive solution, similar to what other advanced apps do in
>> >     Eli> these cases.
>> >
>> > You have to register the yank-media-handler before the yank-media
>> > call, so org canʼt control this: it has to register for "image/.*"
>> > because it canʼt know what formats will be presented to it. I guess it
>> > could have a user option to filter the results from inside its
>> > yank-media-handler, but then *every* package that wants to support
>> > image yanking will have to implement something similar: we should just
>> > implement such handling in the yank-media code.
>> 
>> AFAIR the yank-media code, there's no way for the handlers to reject a
>> specific format.  yank-media, the command, asks the user the type she
>> wants, _then_ calls the handler specific to that type.  The handler
>> cannot influence anything during this interaction.
>
> This is true, but I don't see how it is relevant to what I suggested.

I was replying to this part:

    The issue at hand here, AFAIU, is not the UI, but how Lisp programs
    (and Org in particular) can control this.

My point was that there is little control over this UI from the handlers
type since the handler cannot filter the types available.

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

[Visuwesh]

[செவ்வாய் செப்டம்பர் 24, 2024] Visuwesh wrote:

> I was replying to this part:
>
>     The issue at hand here, AFAIU, is not the UI, but how Lisp programs
>     (and Org in particular) can control this.
>
> My point was that there is little control over this UI from the handlers
> type since the handler cannot filter the types available.
  ^^^^

Sorry, I meant to write "side" here.

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: rpluim@gmail.com,  pinmacs@cas.cat,  emacs-devel@gnu.org
> Date: Tue, 24 Sep 2024 10:30:49 +0530
> 
> [திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:
> 
> >> AFAIR the yank-media code, there's no way for the handlers to reject a
> >> specific format.  yank-media, the command, asks the user the type she
> >> wants, _then_ calls the handler specific to that type.  The handler
> >> cannot influence anything during this interaction.
> >
> > This is true, but I don't see how it is relevant to what I suggested.
> 
> I was replying to this part:
> 
>     The issue at hand here, AFAIU, is not the UI, but how Lisp programs
>     (and Org in particular) can control this.
> 
> My point was that there is little control over this UI from the handlers
> type since the handler cannot filter the types available.

OK, but then my point was that a Lisp program _can_ control this by
customizing the list of handlers.  It could even replace all the
handlers with its own single handler, which could then call the other
handlers according to some logic, thus working around the fact that
there's no mechanism currently for a handler to refuse to handle the
type for which it is registered.

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

[Visuwesh]

[செவ்வாய் செப்டம்பர் 24, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: rpluim@gmail.com,  pinmacs@cas.cat,  emacs-devel@gnu.org
>> Date: Tue, 24 Sep 2024 10:30:49 +0530
>> 
>> [திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:
>> 
>> >> AFAIR the yank-media code, there's no way for the handlers to reject a
>> >> specific format.  yank-media, the command, asks the user the type she
>> >> wants, _then_ calls the handler specific to that type.  The handler
>> >> cannot influence anything during this interaction.
>> >
>> > This is true, but I don't see how it is relevant to what I suggested.
>> 
>> I was replying to this part:
>> 
>>     The issue at hand here, AFAIU, is not the UI, but how Lisp programs
>>     (and Org in particular) can control this.
>> 
>> My point was that there is little control over this UI from the handlers
>> type since the handler cannot filter the types available.
>
> OK, but then my point was that a Lisp program _can_ control this by
> customizing the list of handlers.  

Perhaps, we view the user option in different lights.  I see the user
option as a knob to narrow down the available types to a few (or one)
types that the user personally wants.

> It could even replace all the handlers with its own single handler,
> which could then call the other handlers according to some logic, thus
> working around the fact that there's no mechanism currently for a
> handler to refuse to handle the type for which it is registered.

If you meant to say use ".*" as TYPES in yank-media-handler that
wouldn't work because the user is asked before yank-media, the command,
calls the handler with the mimetype and the clipboard data.
If you meant something else, then sorry I do not understand what you
wrote.  But your point has gotten across to me, I think.

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Visuwesh <visuweshm@gmail.com>,  pinmacs@cas.cat,  emacs-devel@gnu.org
> Date: Mon, 23 Sep 2024 17:09:03 +0200
> 
>     Eli> IMO, for users we already have what is needed: when we detect several
>     Eli> formats, we show them to the user and ask him/her to tell us which
>     Eli> format he/she wants to use.
> 
> But that requires user interaction. I think the original request could
> be summed up as "if the list contains image/png, donʼt ask me, just
> insert the image".

That's not how I understand the request.  It was not always PNG, it
was "sometimes PNG, but if so-and-so-happens, the JPEG" etc.

I'm okay with having C-y select one format, if we can come up with
some reasonable default, but we need to discuss the algorithm to
arrive at that default.  And if the suggestion is to let users write a
function to make that decision, then I'm squarely against that,
because providing such functions is the job of Lisp programs.

>     Eli> The issue at hand here, AFAIU, is not the UI, but how Lisp programs
>     Eli> (and Org in particular) can control this.  If the issue is the user
>     Eli> interface, then I honestly don't understand what issue is being
>     Eli> brought up, because in that case we already have the correct and
>     Eli> comprehensive solution, similar to what other advanced apps do in
>     Eli> these cases.
> 
> You have to register the yank-media-handler before the yank-media
> call, so org canʼt control this: it has to register for "image/.*"
> because it canʼt know what formats will be presented to it. I guess it
> could have a user option to filter the results from inside its
> yank-media-handler, but then *every* package that wants to support
> image yanking will have to implement something similar: we should just
> implement such handling in the yank-media code.

How else would you pull such a trick?

And no one has explained yet why I would prefer PNG to JPEG or vice
versa, btw.  The usual choices I'm familiar with is whether or not to
preserve typefaces, colors, and other fancy attributes; regarding
images, there's just a decision whether you want to paste the material
as a picture or as some kind of text, whether rich or not.  So the
background and the context for this request is still not clear to me.

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

[Robert Pluim]

>>>>> On Mon, 23 Sep 2024 18:54:25 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Visuwesh <visuweshm@gmail.com>,  pinmacs@cas.cat,  emacs-devel@gnu.org
    >> Date: Mon, 23 Sep 2024 17:09:03 +0200
    >> 
    Eli> IMO, for users we already have what is needed: when we detect several
    Eli> formats, we show them to the user and ask him/her to tell us which
    Eli> format he/she wants to use.
    >> 
    >> But that requires user interaction. I think the original request could
    >> be summed up as "if the list contains image/png, donʼt ask me, just
    >> insert the image".

    Eli> That's not how I understand the request.  It was not always PNG, it
    Eli> was "sometimes PNG, but if so-and-so-happens, the JPEG" etc.

Yes, but the "so-and-so" is determined by a user option. So

1. Always prefer "png" -> user option == "png"
2. Want to choose between "png" and "jpeg" -> user option == ("png"
"jpeg")
3. All of the formats -> user option == nil

    Eli> I'm okay with having C-y select one format, if we can come up with
    Eli> some reasonable default, but we need to discuss the algorithm to
    Eli> arrive at that default.  And if the suggestion is to let users write a
    Eli> function to make that decision, then I'm squarely against that,
    Eli> because providing such functions is the job of Lisp programs.

I donʼt think putting a single format on C-y works for case 2. I guess
we could pre-populate the future history with one or more formats, but
I think the user option would work better.

The algorithm would be 'select all the formats in the available list
that are in the user option. If that results in an empty list, offer
the original list. If it results in a list that has one element, use
it, else offer the shortened list'

    Eli> And no one has explained yet why I would prefer PNG to JPEG or vice
    Eli> versa, btw.  The usual choices I'm familiar with is whether or not to
    Eli> preserve typefaces, colors, and other fancy attributes; regarding
    Eli> images, there's just a decision whether you want to paste the material
    Eli> as a picture or as some kind of text, whether rich or not.  So the
    Eli> background and the context for this request is still not clear to me.

I can definitely see a use for case 1 above: "donʼt bother asking me,
if png is available just use that".

Robert
-- 

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: visuweshm@gmail.com,  pinmacs@cas.cat,  emacs-devel@gnu.org
> Date: Mon, 23 Sep 2024 18:10:43 +0200
> 
> >>>>> On Mon, 23 Sep 2024 18:54:25 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: Visuwesh <visuweshm@gmail.com>,  pinmacs@cas.cat,  emacs-devel@gnu.org
>     >> Date: Mon, 23 Sep 2024 17:09:03 +0200
>     >> 
>     Eli> IMO, for users we already have what is needed: when we detect several
>     Eli> formats, we show them to the user and ask him/her to tell us which
>     Eli> format he/she wants to use.
>     >> 
>     >> But that requires user interaction. I think the original request could
>     >> be summed up as "if the list contains image/png, donʼt ask me, just
>     >> insert the image".
> 
>     Eli> That's not how I understand the request.  It was not always PNG, it
>     Eli> was "sometimes PNG, but if so-and-so-happens, the JPEG" etc.
> 
> Yes, but the "so-and-so" is determined by a user option. So
> 
> 1. Always prefer "png" -> user option == "png"
> 2. Want to choose between "png" and "jpeg" -> user option == ("png"
> "jpeg")
> 3. All of the formats -> user option == nil

That makes little sense to me: how can the user decide in advance to
use only PNG? by what logic?

And anyway, this is not what the OP said.  Let's get back to what he
said:

>     Eli> And no one has explained yet why I would prefer PNG to JPEG or vice
>     Eli> versa, btw.  The usual choices I'm familiar with is whether or not to
>     Eli> preserve typefaces, colors, and other fancy attributes; regarding
>     Eli> images, there's just a decision whether you want to paste the material
>     Eli> as a picture or as some kind of text, whether rich or not.  So the
>     Eli> background and the context for this request is still not clear to me.
> 
> I can definitely see a use for case 1 above: "donʼt bother asking me,
> if png is available just use that".

I don't understand why would someone define their preference in the
terms of image format.  It makes no sense.

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

[pinmacs]

Before yank-media, I was using org-download [1], so I got used to just 
insert a screenshot with no question to answer (such as the type of the 
image).

Recently, I moved to yank-media, but to have the same functionality, I 
had to tweak it a little bit, full detail here [2].

I see utility on asking for the image/png and image/jpeg and here you 
have details why you would care about [3]. But I am not familiar with 
image/pbm, image/xbm, image/xpm, image/tiff; for me, it is a nonsense to 
appear as types to select. But maybe somebody wants them, so that's why 
an option to pre-filter (or not) the candidates; and also the option to 
just stick with png (and save a keystroke, and a nonrelevant decision).

[1] https://github.com/abo-abo/org-download

[2] https://mail.gnu.org/archive/html/emacs-orgmode/2024-09/msg00209.html

[3]

   > The JPEG compression algorithm operates at its best on photographs
   > and paintings of realistic scenes with smooth variations of tone
   > and color (...) However, JPEG is not well suited for line drawings
   > and other textual or iconic graphics, where the sharp contrasts
   > between adjacent pixels can cause noticeable artifacts. Such
   > images are better saved in a lossless graphics format such as
   > TIFF, GIF, PNG, or a raw image format. The JPEG standard includes
   > a lossless coding mode, but that mode is not supported in most
   > products.

   https://en.wikipedia.org/wiki/JPEG#Typical_use

   > The JPEG (Joint Photographic Experts Group) format can produce a
   > smaller file than PNG for photographic (and photo-like) images,
   > since JPEG uses a lossy encoding method specifically designed for
   > photographic image data, which is typically dominated by soft,
   > low-contrast transitions, and an amount of noise or similar
   > irregular structures. Using PNG instead of a high-quality JPEG for
   > such images would result in a large increase in file size with
   > negligible gain in quality. In comparison, when storing images
   > that contain text, line art, or graphics – images with sharp
   > transitions and large areas of solid color – the PNG format can
   > compress image data more than JPEG can. Additionally, PNG is
   > lossless, while JPEG produces visual artifacts around
   > high-contrast areas.

   https://en.wikipedia.org/wiki/PNG#JPEG

On 2024-09-23 13:34, Eli Zaretskii wrote:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: visuweshm@gmail.com,  pinmacs@cas.cat,  emacs-devel@gnu.org
>> Date: Mon, 23 Sep 2024 18:10:43 +0200
>>
>>>>>>> On Mon, 23 Sep 2024 18:54:25 +0300, Eli Zaretskii <eliz@gnu.org> said:
>>      >> From: Robert Pluim <rpluim@gmail.com>
>>      >> Cc: Visuwesh <visuweshm@gmail.com>,  pinmacs@cas.cat,  emacs-devel@gnu.org
>>      >> Date: Mon, 23 Sep 2024 17:09:03 +0200
>>      >>
>>      Eli> IMO, for users we already have what is needed: when we detect several
>>      Eli> formats, we show them to the user and ask him/her to tell us which
>>      Eli> format he/she wants to use.
>>      >>
>>      >> But that requires user interaction. I think the original request could
>>      >> be summed up as "if the list contains image/png, donʼt ask me, just
>>      >> insert the image".
>>
>>      Eli> That's not how I understand the request.  It was not always PNG, it
>>      Eli> was "sometimes PNG, but if so-and-so-happens, the JPEG" etc.
>>
>> Yes, but the "so-and-so" is determined by a user option. So
>>
>> 1. Always prefer "png" -> user option == "png"
>> 2. Want to choose between "png" and "jpeg" -> user option == ("png"
>> "jpeg")
>> 3. All of the formats -> user option == nil
> That makes little sense to me: how can the user decide in advance to
> use only PNG? by what logic?
>
> And anyway, this is not what the OP said.  Let's get back to what he
> said:
>
>>      Eli> And no one has explained yet why I would prefer PNG to JPEG or vice
>>      Eli> versa, btw.  The usual choices I'm familiar with is whether or not to
>>      Eli> preserve typefaces, colors, and other fancy attributes; regarding
>>      Eli> images, there's just a decision whether you want to paste the material
>>      Eli> as a picture or as some kind of text, whether rich or not.  So the
>>      Eli> background and the context for this request is still not clear to me.
>>
>> I can definitely see a use for case 1 above: "donʼt bother asking me,
>> if png is available just use that".
> I don't understand why would someone define their preference in the
> terms of image format.  It makes no sense.
>

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

[Eli Zaretskii]

> Date: Mon, 23 Sep 2024 15:00:54 -0300
> Cc: visuweshm@gmail.com, emacs-devel@gnu.org
> From: pinmacs <pinmacs@cas.cat>
> 
> Before yank-media, I was using org-download [1], so I got used to just 
> insert a screenshot with no question to answer (such as the type of the 
> image).
> 
> Recently, I moved to yank-media, but to have the same functionality, I 
> had to tweak it a little bit, full detail here [2].
> 
> I see utility on asking for the image/png and image/jpeg and here you 
> have details why you would care about [3].

This just says that PNG is always preferable to JPEG if both are
available.  As I already said, I'm okay with the idea of having C-y or
similar key to decide which format to use, and so what you are saying
(and I agree) that it should always choose PNG if Emacs supports it.

What I still do not understand is what would be the reason for the
user to prefer JPEG over PNG.  More generally, if Emacs can support N
formats out of those available in the clipboard, why would the user
want to be shown only 1 < M < N out of them?

Furthermore, your request was even more broad and general: it asked
for some filtering infrastructure, and I'm still trying to understand
why that would be needed.  The discussion to which you point on the
Org list doesn't explain the rationale, either.

Bottom line: I'm okay with offering two yank-media alternatives:

(1) via a command that selects a single most appropriate format based
on some (yet to be defined) algorithm; and
(2) via showing the list of all the formats that the running Emacs
supports and asking the user to choose one.

If we can agree on this, we should now discuss those algorithms for
selecting a single media type.

Thanks.

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

[Pedro]

[-- Attachment #1.1.1: Type: text/plain, Size: 4009 bytes --]

Eli, I think we can solve the three situations described with following 
algorithm/idea/inspiration [1]: through a configurable variable 
(yank-media-image-types ?). That would allow you to be able to select 
among all options (that for certain cases could be interesting, say 
"expert mode", I know what I am doing, verbose mode, etc.), and also, a 
way to filter out certain candidates based on what you need.

Making that variable equal to nil would be as it is now, and configuring 
it to "image/png", would only select one. I think others were thinking 
about a regex. As you wish, I only need some sort of filter, and I don't 
care too much on the detail of how it is configured.

[1]
#+begin_src emacs-lisp

(defun my/filter (lst allowed)
   "Filter elements from LST based on ALLOWED. If no match is found, 
return LST."
   (if (null allowed)
       lst
     (let ((filtered
            (delq nil (mapcar
                       (lambda (x)
                         (when
                             (member x allowed) x)) lst))))
       (if (null filtered) lst filtered))))

(defun my/select (lst allowed)
   (if (equal (length allowed) 1)
       allowed
     (completing-read
      "Several types available, choose one:"
      (my/filter lst allowed))))

(setq my/candidates '("image/png"
                       "image/pbm"
                       "image/xbm"
                       "image/xpm"
                       "image/jpeg"
                       "image/tiff"
                       "image/webp"))

;; 1. I only want png
(my/select my/candidates '("image/png"))
;; 2. I only want to select between png and/or jpeg
(my/select my/candidates '("image/png" "image/jpeg"))
;; 3. expert mode (just like it is now)
(my/select my/candidates nil)

;; example of how you would customize the variable
(setq yank-media-image-types '("image/png"))
#+end_src

On 2024-09-23 15:35, Eli Zaretskii wrote:
>> Date: Mon, 23 Sep 2024 15:00:54 -0300
>> Cc: visuweshm@gmail.com, emacs-devel@gnu.org
>> From: pinmacs <pinmacs@cas.cat>
>>
>> Before yank-media, I was using org-download [1], so I got used to just
>> insert a screenshot with no question to answer (such as the type of the
>> image).
>>
>> Recently, I moved to yank-media, but to have the same functionality, I
>> had to tweak it a little bit, full detail here [2].
>>
>> I see utility on asking for the image/png and image/jpeg and here you
>> have details why you would care about [3].
> This just says that PNG is always preferable to JPEG if both are
> available.  As I already said, I'm okay with the idea of having C-y or
> similar key to decide which format to use, and so what you are saying
> (and I agree) that it should always choose PNG if Emacs supports it.
>
> What I still do not understand is what would be the reason for the
> user to prefer JPEG over PNG.  More generally, if Emacs can support N
> formats out of those available in the clipboard, why would the user
> want to be shown only 1 < M < N out of them?
>
> Furthermore, your request was even more broad and general: it asked
> for some filtering infrastructure, and I'm still trying to understand
> why that would be needed.  The discussion to which you point on the
> Org list doesn't explain the rationale, either.
>
> Bottom line: I'm okay with offering two yank-media alternatives:
>
> (1) via a command that selects a single most appropriate format based
> on some (yet to be defined) algorithm; and
> (2) via showing the list of all the formats that the running Emacs
> supports and asking the user to choose one.
>
> If we can agree on this, we should now discuss those algorithms for
> selecting a single media type.
>
> Thanks.
>


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3323 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[pinmacs]

Eli, I think we can solve the three situations described with following 
algorithm/idea/inspiration [1]: through a configurable variable 
(yank-media-image-types ?). That would allow you to be able to select 
among all options (that for certain cases could be interesting, say 
"expert mode", I know what I am doing, verbose mode, etc.), and also, a 
way to filter out certain candidates based on what you need.

Making that variable equal to nil would be as it is now, and configuring 
it to "image/png", would only select one. I think others were thinking 
about a regex. As you wish, I only need some sort of filter, and I don't 
care too much on the detail of how it is configured.

[1]
#+begin_src emacs-lisp

(defun my/filter (lst allowed)
   "Filter elements from LST based on ALLOWED. If no match is found, 
return LST."
   (if (null allowed)
       lst
     (let ((filtered
            (delq nil (mapcar
                       (lambda (x)
                         (when
                             (member x allowed) x)) lst))))
       (if (null filtered) lst filtered))))

(defun my/select (lst allowed)
   (if (equal (length allowed) 1)
       allowed
     (completing-read
      "Several types available, choose one:"
      (my/filter lst allowed))))

(setq my/candidates '("image/png"
                       "image/pbm"
                       "image/xbm"
                       "image/xpm"
                       "image/jpeg"
                       "image/tiff"
                       "image/webp"))

;; 1. I only want png
(my/select my/candidates '("image/png"))
;; 2. I only want to select between png and/or jpeg
(my/select my/candidates '("image/png" "image/jpeg"))
;; 3. expert mode (just like it is now)
(my/select my/candidates nil)

;; example of how you would customize the variable
(setq yank-media-image-types '("image/png"))
#+end_src

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

[Robert Pluim]

>>>>> On Mon, 23 Sep 2024 18:08:58 -0300, pinmacs <pinmacs@cas.cat> said:

    pinmacs> Eli, I think we can solve the three situations described with following 
    pinmacs> algorithm/idea/inspiration [1]: through a configurable variable 
    pinmacs> (yank-media-image-types ?). That would allow you to be able to select 
    pinmacs> among all options (that for certain cases could be interesting, say 
    pinmacs> "expert mode", I know what I am doing, verbose mode, etc.), and also, a 
    pinmacs> way to filter out certain candidates based on what you need.

    pinmacs> Making that variable equal to nil would be as it is now, and configuring 
    pinmacs> it to "image/png", would only select one. I think others were thinking 
    pinmacs> about a regex. As you wish, I only need some sort of filter, and I don't 
    pinmacs> care too much on the detail of how it is configured.

    pinmacs> [1]

    pinmacs> #+begin_src emacs-lisp

    pinmacs> (defun my/filter (lst allowed)
    pinmacs>    "Filter elements from LST based on ALLOWED. If no match is found, 
    pinmacs> return LST."
    pinmacs>    (if (null allowed)
    pinmacs>        lst
    pinmacs>      (let ((filtered
    pinmacs>             (delq nil (mapcar
    pinmacs>                        (lambda (x)
    pinmacs>                          (when
    pinmacs>                              (member x allowed) x)) lst))))
    pinmacs>        (if (null filtered) lst filtered))))

    pinmacs> (defun my/select (lst allowed)
    pinmacs>    (if (equal (length allowed) 1)
    pinmacs>        allowed
    pinmacs>      (completing-read
    pinmacs>       "Several types available, choose one:"
    pinmacs>       (my/filter lst allowed))))

You need to filter the candidate list before you decide whether to use
`completing-read'. And use `cl-intersection' ☺️

Robert
-- 

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

[Eli Zaretskii]

> Date: Mon, 23 Sep 2024 18:08:58 -0300
> Cc: rpluim@gmail.com, visuweshm@gmail.com, emacs-devel@gnu.org
> From: pinmacs <pinmacs@cas.cat>
> 
> Eli, I think we can solve the three situations described with following 
> algorithm/idea/inspiration [1]: through a configurable variable 
> (yank-media-image-types ?). That would allow you to be able to select 
> among all options (that for certain cases could be interesting, say 
> "expert mode", I know what I am doing, verbose mode, etc.), and also, a 
> way to filter out certain candidates based on what you need.
> 
> Making that variable equal to nil would be as it is now, and configuring 
> it to "image/png", would only select one. I think others were thinking 
> about a regex. As you wish, I only need some sort of filter, and I don't 
> care too much on the detail of how it is configured.

First, I think a simple defcustom will not be enough, since changing
the list of handlers must go through yank-media-handler.

More importantly, I still don't understand the rationale and the use
cases where this could be useful, and adding yet another user option
without understanding its need and intended usage is not something I'd
like us to do.  Emacs already has way too many user options.

Thanks.

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

[Robert Pluim]

>>>>> On Tue, 24 Sep 2024 14:30:01 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Mon, 23 Sep 2024 18:08:58 -0300
    >> Cc: rpluim@gmail.com, visuweshm@gmail.com, emacs-devel@gnu.org
    >> From: pinmacs <pinmacs@cas.cat>
    >> 
    >> Eli, I think we can solve the three situations described with following 
    >> algorithm/idea/inspiration [1]: through a configurable variable 
    >> (yank-media-image-types ?). That would allow you to be able to select 
    >> among all options (that for certain cases could be interesting, say 
    >> "expert mode", I know what I am doing, verbose mode, etc.), and also, a 
    >> way to filter out certain candidates based on what you need.
    >> 
    >> Making that variable equal to nil would be as it is now, and configuring 
    >> it to "image/png", would only select one. I think others were thinking 
    >> about a regex. As you wish, I only need some sort of filter, and I don't 
    >> care too much on the detail of how it is configured.

    Eli> First, I think a simple defcustom will not be enough, since changing
    Eli> the list of handlers must go through yank-media-handler.

Thereʼs no need to change the list of handlers. What the user option
would change is only which type(s) are presented to the user. The
mapping from the selected type to the handler doesnʼt need to be
changed. eg org uses the same handler for all image types.

    Eli> More importantly, I still don't understand the rationale and the use
    Eli> cases where this could be useful, and adding yet another user option
    Eli> without understanding its need and intended usage is not something I'd
    Eli> like us to do.  Emacs already has way too many user options.

When writing technical documentation, often you want to include
screenshots, eg of a browser window. On my GNU/Linux box, `yank-media'
of such a screenshot offers jpeg, png, or webp as formats and I have
to choose which one I want every time. If I could say "use png if
available" via our proposed user option, that would save me time and
would interrupt my flow less. Or if I was yanking text from a word
processor, I could say "prefer plain text" since I donʼt want to deal
with any potential html markup.

Itʼs analogous to the situation where people send
multipart/alternative emails with both a text/plain and a text/html
part, and the recipient specifies which of those theyʼd prefer to see.

Robert
-- 

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: pinmacs <pinmacs@cas.cat>,  visuweshm@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 24 Sep 2024 14:18:08 +0200
> 
> >>>>> On Tue, 24 Sep 2024 14:30:01 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> First, I think a simple defcustom will not be enough, since changing
>     Eli> the list of handlers must go through yank-media-handler.
> 
> Thereʼs no need to change the list of handlers. What the user option
> would change is only which type(s) are presented to the user. The
> mapping from the selected type to the handler doesnʼt need to be
> changed. eg org uses the same handler for all image types.

So this option can only be used to effectively disable some handlers,
and cannot be used to _add_ handlers?  Does that make sense?

>     Eli> More importantly, I still don't understand the rationale and the use
>     Eli> cases where this could be useful, and adding yet another user option
>     Eli> without understanding its need and intended usage is not something I'd
>     Eli> like us to do.  Emacs already has way too many user options.
> 
> When writing technical documentation, often you want to include
> screenshots, eg of a browser window. On my GNU/Linux box, `yank-media'
> of such a screenshot offers jpeg, png, or webp as formats and I have
> to choose which one I want every time.

And this is a frequent enough situation to justify a new user option?
How much does this happen to you when you write documentation?

Moreover, why would you want to prefer a specific image type in this
case?  I think this case is exactly the reason for having a command
that automatically chooses the most appropriate image format without
asking you.

> Or if I was yanking text from a word processor, I could say "prefer
> plain text" since I donʼt want to deal with any potential html
> markup.

Here' too, it should be possible for Emacs to choose the most
appropriate format automatically.  For example, if yanking into a
plain text buffer, prefer plain text; when yanking into rich text,
prefer text with faces, etc.

> Itʼs analogous to the situation where people send
> multipart/alternative emails with both a text/plain and a text/html
> part, and the recipient specifies which of those theyʼd prefer to see.

Yes, and how many times you want the part that was not the one shown
by default?  In my case, this happens extremely rarely, almost only
when the default format has some problem, like is unreadable for some
reason.

Bottom line, I think we will be much better off if we offer a command
that automatically yanks the most appropriate format.

But we are already going in circles, so I hope someone has some new
arguments and use cases that were not yet brought up.

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

[Visuwesh]

[செவ்வாய் செப்டம்பர் 24, 2024] Eli Zaretskii wrote:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: pinmacs <pinmacs@cas.cat>,  visuweshm@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 24 Sep 2024 14:18:08 +0200
>> 
>> >>>>> On Tue, 24 Sep 2024 14:30:01 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> 
>>     Eli> First, I think a simple defcustom will not be enough, since changing
>>     Eli> the list of handlers must go through yank-media-handler.
>> 
>> Thereʼs no need to change the list of handlers. What the user option
>> would change is only which type(s) are presented to the user. The
>> mapping from the selected type to the handler doesnʼt need to be
>> changed. eg org uses the same handler for all image types.
>
> So this option can only be used to effectively disable some handlers,
> and cannot be used to _add_ handlers?  Does that make sense?

Yes.  Adding handlers would be done using yank-media-handler, as before.

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  pinmacs@cas.cat,  emacs-devel@gnu.org
> Date: Tue, 24 Sep 2024 19:08:24 +0530
> 
> [செவ்வாய் செப்டம்பர் 24, 2024] Eli Zaretskii wrote:
> 
> >> From: Robert Pluim <rpluim@gmail.com>
> >> Cc: pinmacs <pinmacs@cas.cat>,  visuweshm@gmail.com,  emacs-devel@gnu.org
> >> Date: Tue, 24 Sep 2024 14:18:08 +0200
> >> 
> >> >>>>> On Tue, 24 Sep 2024 14:30:01 +0300, Eli Zaretskii <eliz@gnu.org> said:
> >> 
> >>     Eli> First, I think a simple defcustom will not be enough, since changing
> >>     Eli> the list of handlers must go through yank-media-handler.
> >> 
> >> Thereʼs no need to change the list of handlers. What the user option
> >> would change is only which type(s) are presented to the user. The
> >> mapping from the selected type to the handler doesnʼt need to be
> >> changed. eg org uses the same handler for all image types.
> >
> > So this option can only be used to effectively disable some handlers,
> > and cannot be used to _add_ handlers?  Does that make sense?
> 
> Yes.  Adding handlers would be done using yank-media-handler, as before.

That's not how we design user options.

But anyway, I don't think we need such an option.

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

[Visuwesh]

[திங்கள் செப்டம்பர் 23, 2024] Eli Zaretskii wrote:

>> Date: Mon, 23 Sep 2024 15:00:54 -0300
>> Cc: visuweshm@gmail.com, emacs-devel@gnu.org
>> From: pinmacs <pinmacs@cas.cat>
>> 
>> Before yank-media, I was using org-download [1], so I got used to just 
>> insert a screenshot with no question to answer (such as the type of the 
>> image).
>> 
>> Recently, I moved to yank-media, but to have the same functionality, I 
>> had to tweak it a little bit, full detail here [2].
>> 
>> I see utility on asking for the image/png and image/jpeg and here you 
>> have details why you would care about [3].
>
> This just says that PNG is always preferable to JPEG if both are
> available.  As I already said, I'm okay with the idea of having C-y or
> similar key to decide which format to use, and so what you are saying
> (and I agree) that it should always choose PNG if Emacs supports it.
>
> What I still do not understand is what would be the reason for the
> user to prefer JPEG over PNG.  More generally, if Emacs can support N
> formats out of those available in the clipboard, why would the user
> want to be shown only 1 < M < N out of them?

[ The more I think about this, the more I believe the choice of
  "preferred formats" will change depending on the scenario where
  yank-media is used.  In Org, I could see "don't bother asking me, just
  use PNG if available" could be useful.  But somewhere in HTML mode,
  "always ask me" could be the right choice.  ]

> Furthermore, your request was even more broad and general: it asked
> for some filtering infrastructure, and I'm still trying to understand
> why that would be needed.  The discussion to which you point on the
> Org list doesn't explain the rationale, either.
>
> Bottom line: I'm okay with offering two yank-media alternatives:
>
> (1) via a command that selects a single most appropriate format based
> on some (yet to be defined) algorithm; and

What about a user option yank-media-preferred-mimetypes which is a list
of mimetypes that the user would like to always opt for, given the
choice?

. If there is only mimetype available, then we simply choose that type's
  handler without consulting the user option.

. If there are more than one mimetype available, we pick those mimetypes
  that are in the user option.

    . If more than one mimetype from the user option is matched, we ask
      the user what format, among the matched, they want to use.
    . If none of the mimetypes available match those in the user option,
      we again ask the user to choose from all available formats (we
      delegate to option (2) below)


> (2) via showing the list of all the formats that the running Emacs
> supports and asking the user to choose one.

This is what we already have so nothing to be changed.

> If we can agree on this, we should now discuss those algorithms for
> selecting a single media type.
>
> Thanks.

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: pinmacs <pinmacs@cas.cat>,  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 24 Sep 2024 10:38:53 +0530
> 
> > What I still do not understand is what would be the reason for the
> > user to prefer JPEG over PNG.  More generally, if Emacs can support N
> > formats out of those available in the clipboard, why would the user
> > want to be shown only 1 < M < N out of them?
> 
> [ The more I think about this, the more I believe the choice of
>   "preferred formats" will change depending on the scenario where
>   yank-media is used.  In Org, I could see "don't bother asking me, just
>   use PNG if available" could be useful.  But somewhere in HTML mode,
>   "always ask me" could be the right choice.  ]

Which is why I suggested two separate commands: one where the user
says he/she wants the most appropriate type, the other to allow
selection.

> > Bottom line: I'm okay with offering two yank-media alternatives:
> >
> > (1) via a command that selects a single most appropriate format based
> > on some (yet to be defined) algorithm; and
> 
> What about a user option yank-media-preferred-mimetypes which is a list
> of mimetypes that the user would like to always opt for, given the
> choice?

That was proposed earlier in this thread, and I responded: I'm not
sure I understand when and why would this option be needed _as_ a user
option.

> > (2) via showing the list of all the formats that the running Emacs
> > supports and asking the user to choose one.
> 
> This is what we already have so nothing to be changed.

Right.

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

[Visuwesh]

[செவ்வாய் செப்டம்பர் 24, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: pinmacs <pinmacs@cas.cat>,  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 24 Sep 2024 10:38:53 +0530
>> 
>> > What I still do not understand is what would be the reason for the
>> > user to prefer JPEG over PNG.  More generally, if Emacs can support N
>> > formats out of those available in the clipboard, why would the user
>> > want to be shown only 1 < M < N out of them?
>> 
>> [ The more I think about this, the more I believe the choice of
>>   "preferred formats" will change depending on the scenario where
>>   yank-media is used.  In Org, I could see "don't bother asking me, just
>>   use PNG if available" could be useful.  But somewhere in HTML mode,
>>   "always ask me" could be the right choice.  ]
>
> Which is why I suggested two separate commands: one where the user
> says he/she wants the most appropriate type, the other to allow
> selection.

We could make C-u choose the other "mode of operating" since it is
currently free.  Whether we default to asking, or choose the appropriate
one can be decided later on.

>> > Bottom line: I'm okay with offering two yank-media alternatives:
>> >
>> > (1) via a command that selects a single most appropriate format based
>> > on some (yet to be defined) algorithm; and
>> 
>> What about a user option yank-media-preferred-mimetypes which is a list
>> of mimetypes that the user would like to always opt for, given the
>> choice?
>
> That was proposed earlier in this thread, and I responded: I'm not
> sure I understand when and why would this option be needed _as_ a user
> option.

I hope Robert shed some light in the other thread on this.

I haven't encountered many "multiple types available" scenario outside
of Firefox and LibreOffice.  In most cases, yank-media just does the
thing without interrupting me but when the uncommon case of "multiple
types available" crops up, I would like yank-media to choose the type I
want automatically for me.  In Org, I personally would make yank-media
choose image/png.  If you ask me for technical reasons to prefer
image/png specifically, I cannot give you a concrete answer. It might as
well be image/jpeg for all I care.  I simply do not want to be asked a
question when I'm focusing on writing.  The point of the user option is
to keep user interaction to a minimum.

>> > (2) via showing the list of all the formats that the running Emacs
>> > supports and asking the user to choose one.
>> 
>> This is what we already have so nothing to be changed.
>
> Right.

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: pinmacs@cas.cat,  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 24 Sep 2024 18:20:21 +0530
> 
> I haven't encountered many "multiple types available" scenario outside
> of Firefox and LibreOffice.  In most cases, yank-media just does the
> thing without interrupting me but when the uncommon case of "multiple
> types available" crops up, I would like yank-media to choose the type I
> want automatically for me.  In Org, I personally would make yank-media
> choose image/png.  If you ask me for technical reasons to prefer
> image/png specifically, I cannot give you a concrete answer. It might as
> well be image/jpeg for all I care.  I simply do not want to be asked a
> question when I'm focusing on writing.  The point of the user option is
> to keep user interaction to a minimum.

I think if PNG is supported by the running Emacs, it is always
preferable.  (And we can come up with the list image formats ordered
by their preference, and use that to find the first available one.)

I do agree that in many/most cases having Emacs deduce the best format
automatically is a very useful feature to have.  I also agree that it
is useful to be able to see the list of available formats and choose
from them.  I just think that these two extremities is all we need,
provided that we can come up with a good algorithm for deciding the
"most appropriate format" in each case.

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

[Visuwesh]

[செவ்வாய் செப்டம்பர் 24, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: pinmacs@cas.cat,  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 24 Sep 2024 18:20:21 +0530
>> 
>> I haven't encountered many "multiple types available" scenario outside
>> of Firefox and LibreOffice.  In most cases, yank-media just does the
>> thing without interrupting me but when the uncommon case of "multiple
>> types available" crops up, I would like yank-media to choose the type I
>> want automatically for me.  In Org, I personally would make yank-media
>> choose image/png.  If you ask me for technical reasons to prefer
>> image/png specifically, I cannot give you a concrete answer. It might as
>> well be image/jpeg for all I care.  I simply do not want to be asked a
>> question when I'm focusing on writing.  The point of the user option is
>> to keep user interaction to a minimum.
>
> I think if PNG is supported by the running Emacs, it is always
> preferable.  (And we can come up with the list image formats ordered
> by their preference, and use that to find the first available one.)
>
> I do agree that in many/most cases having Emacs deduce the best format
> automatically is a very useful feature to have.  I also agree that it
> is useful to be able to see the list of available formats and choose
> from them.

So then we do agree.

> I just think that these two extremities is all we need, provided that
> we can come up with a good algorithm for deciding the "most
> appropriate format" in each case.

This is where we disagree: I think it would be best if we leave this
choice to the user.  I do not think it is possible to come up with a
"one size fits all" solution that works across all the handlers.  We
could leave the job of deciding the "most appropriate format" to the
major-mode but I am afraid it will only produce even more user options
which would be too chaotic to manage.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> What about a user option yank-media-preferred-mimetypes which is a list
>> of mimetypes that the user would like to always opt for, given the
>> choice?
>
> That was proposed earlier in this thread, and I responded: I'm not
> sure I understand when and why would this option be needed _as_ a user
> option.

Does it mean that you are not against an equivalent variable that can be
used from Elisp? I think that it might be good enough for Org mode
purposes and, if deemed necessary, may be later converted to user option.

(It has been over a month since the last activity of this thread, and I
want it to go at least somewhere).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Visuwesh <visuweshm@gmail.com>, pinmacs@cas.cat, rpluim@gmail.com,
>  emacs-devel@gnu.org
> Date: Sat, 26 Oct 2024 17:27:06 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> What about a user option yank-media-preferred-mimetypes which is a list
> >> of mimetypes that the user would like to always opt for, given the
> >> choice?
> >
> > That was proposed earlier in this thread, and I responded: I'm not
> > sure I understand when and why would this option be needed _as_ a user
> > option.

[It's hard to pick up a discussion which stopped a month ago.]

> Does it mean that you are not against an equivalent variable that can be
> used from Elisp? I think that it might be good enough for Org mode
> purposes and, if deemed necessary, may be later converted to user option.

If a Lisp program wants to control which MIME types are preferred, it
can do that already by changing the list of handlers, no?  I'm sure I
said that at some point in the discussion.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>
>> Does it mean that you are not against an equivalent variable that can be
>> used from Elisp? I think that it might be good enough for Org mode
>> purposes and, if deemed necessary, may be later converted to user option.
>
> If a Lisp program wants to control which MIME types are preferred, it
> can do that already by changing the list of handlers, no?  I'm sure I
> said that at some point in the discussion.

Let me try to explain in my own words.

Consider the following 3 scenarios:

1. clipboard contains 2 MIME types: image/png, image/bmp
2. clipboard contains 1 MIME type: image/png
3. clipboard contains 1 MIME type: image/bmp

We want to handle all three scenarios in the following way:
1. Select image/png (prefer it over image/bmp)
2. Select image/png
3. Select image/bmp (there is no image/png that we would prefer otherwise)

In all three cases, we do not want to prompt user about mimetype choice.

How can we do it using the existing Elisp API?

> [It's hard to pick up a discussion which stopped a month ago.]

Aside: It is not the first time you mention this problem, and I am
wondering how can it be. The full discussion is recorded in the mailing
list archives and possibly available from your MUA from thread view (is
it not?).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org
> Date: Sun, 27 Oct 2024 08:17:22 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> 1. clipboard contains 2 MIME types: image/png, image/bmp
> 2. clipboard contains 1 MIME type: image/png
> 3. clipboard contains 1 MIME type: image/bmp
> 
> We want to handle all three scenarios in the following way:
> 1. Select image/png (prefer it over image/bmp)
> 2. Select image/png
> 3. Select image/bmp (there is no image/png that we would prefer otherwise)
> 
> In all three cases, we do not want to prompt user about mimetype choice.
> 
> How can we do it using the existing Elisp API?

Examine the available TARGETS, then bind
yank-media--registered-handlers to the appropriate value when invoking
yank-media.

> > [It's hard to pick up a discussion which stopped a month ago.]
> 
> Aside: It is not the first time you mention this problem, and I am
> wondering how can it be. The full discussion is recorded in the mailing
> list archives and possibly available from your MUA from thread view (is
> it not?).

Try reading every message on this and every other Emacs-related
mailing list (which is what I do), and you will realize that going
back to archives and re-reading the discussions from the beginning is
something I cannot afford.  I must keep discussions in memory or have
them in my short-term archive, right there in the INBOX, so I could
consult the few previous messages immediately with minimal fuss.  A
month in the past is too far, old messages were purged and are no
longer at my fingertips.

Why did you need to wait so long before chiming in again?  Such long
breaks can never do any good, so I respectfully ask to avoid them.

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

[Visuwesh]

[ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org
>> Date: Sun, 27 Oct 2024 08:17:22 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> 1. clipboard contains 2 MIME types: image/png, image/bmp
>> 2. clipboard contains 1 MIME type: image/png
>> 3. clipboard contains 1 MIME type: image/bmp
>> 
>> We want to handle all three scenarios in the following way:
>> 1. Select image/png (prefer it over image/bmp)
>> 2. Select image/png
>> 3. Select image/bmp (there is no image/png that we would prefer otherwise)
>> 
>> In all three cases, we do not want to prompt user about mimetype choice.
>> 
>> How can we do it using the existing Elisp API?
>
> 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?
This approach also means that we would end up with org-yank-media,
html-yank-media, etc. which does not sound better.

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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: Ihor Radchenko <yantar92@posteo.net>,  pinmacs@cas.cat,
>  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 27 Oct 2024 15:06:36 +0530
> 
> [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:
> 
> >> From: Ihor Radchenko <yantar92@posteo.net>
> >> Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org
> >> Date: Sun, 27 Oct 2024 08:17:22 +0000
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> 1. clipboard contains 2 MIME types: image/png, image/bmp
> >> 2. clipboard contains 1 MIME type: image/png
> >> 3. clipboard contains 1 MIME type: image/bmp
> >> 
> >> We want to handle all three scenarios in the following way:
> >> 1. Select image/png (prefer it over image/bmp)
> >> 2. Select image/png
> >> 3. Select image/bmp (there is no image/png that we would prefer otherwise)
> >> 
> >> In all three cases, we do not want to prompt user about mimetype choice.
> >> 
> >> How can we do it using the existing Elisp API?
> >
> > 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?

> This approach also means that we would end up with org-yank-media,
> html-yank-media, etc. which does not sound better.

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.

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

[Visuwesh]

[ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: Ihor Radchenko <yantar92@posteo.net>,  pinmacs@cas.cat,
>>  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 27 Oct 2024 15:06:36 +0530
>> 
>> [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:
>> 
>> >> From: Ihor Radchenko <yantar92@posteo.net>
>> >> Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org
>> >> Date: Sun, 27 Oct 2024 08:17:22 +0000
>> >> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> 1. clipboard contains 2 MIME types: image/png, image/bmp
>> >> 2. clipboard contains 1 MIME type: image/png
>> >> 3. clipboard contains 1 MIME type: image/bmp
>> >> 
>> >> We want to handle all three scenarios in the following way:
>> >> 1. Select image/png (prefer it over image/bmp)
>> >> 2. Select image/png
>> >> 3. Select image/bmp (there is no image/png that we would prefer otherwise)
>> >> 
>> >> In all three cases, we do not want to prompt user about mimetype choice.
>> >> 
>> >> How can we do it using the existing Elisp API?
>> >
>> > 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.  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.

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...  The entire point of
using the library, IMHO, is to leave out this nasty business of handling
the clipboard to a third party.

>> This approach also means that we would end up with org-yank-media,
>> html-yank-media, etc. which does not sound better.
>
> 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.

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

[Eli Zaretskii]

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

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

[Visuwesh]

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

I feel the same too.  I believe it would be more productive if I
proposed a patch of what I am suggesting so that things will be more
clear.  I will try to post one as soon as time permits, and will answer
rest of the questions you've raised in your message then.

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

[Visuwesh]

[-- Attachment #1: Type: text/plain, Size: 6009 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: yank-media-filter.patch --]
[-- Type: text/x-diff, Size: 2576 bytes --]

diff --git a/lisp/yank-media.el b/lisp/yank-media.el
index 563aae85419..30ede069769 100644
--- a/lisp/yank-media.el
+++ b/lisp/yank-media.el
@@ -29,6 +29,12 @@

 (defvar yank-media--registered-handlers nil)

+(defvar-local yank-media-preferred-type-function nil
+  "Function to select preferred mimetypes out of available ones.
+If non-nil, this function is called with a list of mimetype that is
+handled in the current buffer, and should return a list of preferred
+types to use.")
+
 ;;;###autoload
 (defun yank-media ()
   "Yank media (images, HTML and the like) from the clipboard.
@@ -49,18 +55,29 @@ yank-media
     (unless all-types
       (user-error
        "No handler in the current buffer for anything on the clipboard"))
-    ;; We have a handler in the current buffer; if there's just
-    ;; matching type, just call the handler.
-    (if (length= all-types 1)
-        (funcall (cdar all-types) (caar all-types)
-                 (yank-media--get-selection (caar all-types)))
-      ;; More than one type the user for what type to insert.
-      (let ((type
-             (intern
-              (completing-read "Several types available, choose one: "
-                               (mapcar #'car all-types) nil t))))
-        (funcall (alist-get type all-types)
-                 type (yank-media--get-selection type))))))
+    ;; Remove types that are unwanted.
+    (let ((pref-types (funcall (if yank-media-preferred-type-function
+                                   yank-media-preferred-type-function
+                                 #'identity)
+                               (mapcar #'car all-types))))
+      (unless pref-types
+        (user-error
+         ;; FIXME: Improve the error message.
+         "No handler in the current buffer for preferred data types"))
+      ;; We have a handler in the current buffer; if there's just
+      ;; one preferred type, just call the handler.
+      (if (length= pref-types 1)
+          (let ((data (assq (car pref-types) all-types)))
+            (funcall (cdr data) (car pref-types)
+                     (yank-media--get-selection (car pref-types))))
+        ;; More than one type preferred, ask the user for what type to
+        ;; insert.
+        (let ((type
+               (intern
+                (completing-read "Several types available, choose one: "
+                                 pref-types nil t))))
+          (funcall (alist-get type all-types)
+                   type (yank-media--get-selection type)))))))

 (defun yank-media--find-matching-media (handled-type)
   (seq-filter

[-- Attachment #3: Type: text/plain, Size: 641 bytes --]


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]

Eli Zaretskii <eliz@gnu.org> writes:

> Examine the available TARGETS, then bind
> yank-media--registered-handlers to the appropriate value when invoking
> yank-media.

I am surprised that you are suggesting to bind an internal variable that
does not even have a documented format. Moreover, it is even
deliberately hidden behind `yank-media-handler' wrapper.

I will let Visuwesh provide an example code, so that we can
communicate the desired feature better.

>> Aside: It is not the first time you mention this problem, and I am
>> wondering how can it be. The full discussion is recorded in the mailing
>> list archives and possibly available from your MUA from thread view (is
>> it not?).
>
> Try reading every message on this and every other Emacs-related
> mailing list (which is what I do), and you will realize that going
> back to archives and re-reading the discussions from the beginning is
> something I cannot afford.  I must keep discussions in memory or have
> them in my short-term archive, right there in the INBOX, so I could
> consult the few previous messages immediately with minimal fuss.  A
> month in the past is too far, old messages were purged and are no
> longer at my fingertips.

I do it for Org mode and I usually re-read the threads or keep notes.
Of course, Org mode-related lists have lower volume of messages.

> Why did you need to wait so long before chiming in again?  Such long
> breaks can never do any good, so I respectfully ask to avoid them.

I usually try to give people some time to respond. Contributors often
have limited time to spare for Emacs and may respond after weeks.

I will keep in mind that discussions where you participate should better
be followed up earlier.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org
> Date: Mon, 28 Oct 2024 18:39:02 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Examine the available TARGETS, then bind
> > yank-media--registered-handlers to the appropriate value when invoking
> > yank-media.
> 
> I am surprised that you are suggesting to bind an internal variable that
> does not even have a documented format. Moreover, it is even
> deliberately hidden behind `yank-media-handler' wrapper.

This is all very new, and has yet to be tested by the relevant use
cases.  The initial implementation was basically for a single
platform, and thus is from my POV heavily skewed towards that single
platform.  Thus, I don't see the fact that some variable was deemed as
internal by the original implementor as something we cannot change if
we decide it's useful for applications.

In general, how to control which MIME types are used or presented to
users was not part of the original implementation and AFAIR was never
discussed.  The code we have basically assumes that all the MIME types
are relevant and could/should be used in any order.  Based on what I
see on various platforms with many different applications that support
the clipboard, I think this is quite naïve, so we must extend what we
have to support more control, and that might legitimately call for
reassessment of the internal vs public knobs.

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

[Eli Zaretskii]

> Date: Mon, 23 Sep 2024 19:34:48 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: visuweshm@gmail.com, pinmacs@cas.cat, emacs-devel@gnu.org
> 
> And anyway, this is not what the OP said.  Let's get back to what he
> said:

Sorry, I somehow managed to delete this part.  Here's what I intended
to say:

 And anyway, this is not what the OP said.  Let's get back to what he
 said:

  1. In case I want to be fast, I would like to skip that dialog entirely 
  and just use the image/png variant.
  2. In another perspective, I would consider that the relevant decision 
  for a screenshot would be between two of them: image/png and image/jpeg
  3. Another user could argue why the other 5 types are interesting in 
  general or for their particular use case...

  ... but let's stop that discussion here. Looks like filtering image 
  types would be a useful customization for the users. If done as a 
  variable, in certain cases, that could be local binded and specific to 
  some fast function that immediately inserts an image, and in another 
  case, the global var would select only those image types relevant for 
  that particular user.

You pay attention only to the first part, with its 3 cases, but I
think that the main part is the second paragraph, which seems to ask
for a much more wide feature, and doesn't explain its motivation or
context.

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

[Robert Pluim]

>>>>> On Mon, 23 Sep 2024 21:11:50 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Mon, 23 Sep 2024 19:34:48 +0300
    >> From: Eli Zaretskii <eliz@gnu.org>
    >> Cc: visuweshm@gmail.com, pinmacs@cas.cat, emacs-devel@gnu.org
    >> 
    >> And anyway, this is not what the OP said.  Let's get back to what he
    >> said:

    Eli> Sorry, I somehow managed to delete this part.  Here's what I intended
    Eli> to say:

    Eli>  And anyway, this is not what the OP said.  Let's get back to what he
    Eli>  said:

    Eli>   1. In case I want to be fast, I would like to skip that dialog entirely 
    Eli>   and just use the image/png variant.
    Eli>   2. In another perspective, I would consider that the relevant decision 
    Eli>   for a screenshot would be between two of them: image/png and image/jpeg
    Eli>   3. Another user could argue why the other 5 types are interesting in 
    Eli>   general or for their particular use case...

    Eli>   ... but let's stop that discussion here. Looks like filtering image 
    Eli>   types would be a useful customization for the users. If done as a 
    Eli>   variable, in certain cases, that could be local binded and specific to 
    Eli>   some fast function that immediately inserts an image, and in another 
    Eli>   case, the global var would select only those image types relevant for 
    Eli>   that particular user.

    Eli> You pay attention only to the first part, with its 3 cases, but I
    Eli> think that the main part is the second paragraph, which seems to ask
    Eli> for a much more wide feature, and doesn't explain its motivation or
    Eli> context.

I took the second part as 'if we had such a variable, users could
let-bind it around yank-media to get "insert now" behaviour, and have
a global value that trims the available list'.

Robert
--