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

[Pedro]

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

Hi Visuwesh,

Thanks for the patch!! It is very useful to me.

I tested it and it works as I originally expected: reduce the 
interaction to minimum: I don't need to press enter anymore! :)

I also tested it with two types [1]: jpeg and png; and then you see a 
selector with just the two types you care instead of the 7 types that 
flameshot screen capture tool offers.

The approach of this patch permits to have different yank commands with 
different keybindings and context to respond to different needs (For the 
things I care, I end up having two commands, one that is simple and fast 
with the most preferred thing; and the other that gives all flexibility 
and possibilities). So, happy to see flexibility here too.

I would like to know if it can be included upstream as it is or what 
else needs to be done or discussed.

Meanwhile I will add it to my config.

It might be useful to know why this is better: it is less error prone to 
what I have now. Let me explain this: the other day, by mistake (being 
in a hurry) I did several screen captures and I thought I was using .png 
(I usually pick png on the first time, and then, by frequency, it 
appears in the first position because of the completion tool 
(vertico/orderless ?)). But I was wrong, I took .pbm, for that case, 
that was fine, it was notes for me, but it could be the case of having 
screen captures with the wrong format and having difficulty to generate 
them again. This patch and approach helps the user to avoid that risk.

Cheers,
pinmacs

[1]
   (setq-local
     yank-media-preferred-type-function
     (lambda (types)
       (if (or
            (memq 'image/png types)
            (memq 'image/jpeg types))
           (list 'image/png 'image/jpeg)
         types)))


On 2024-10-29 12:29, Visuwesh wrote:
> [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:
>
>>> From: Visuwesh <visuweshm@gmail.com>
>>> Cc: yantar92@posteo.net,  pinmacs@cas.cat,  rpluim@gmail.com,
>>>    emacs-devel@gnu.org
>>> Date: Sun, 27 Oct 2024 20:32:21 +0530
>>>
>>> [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:
>>>
>>>>>> Examine the available TARGETS, then bind
>>>>>> yank-media--registered-handlers to the appropriate value when invoking
>>>>>> yank-media.
>>>>> Would that not defeat the point of yank-media, which is to present a
>>>>> simple, common interface to the clipboard data to major-mode authors?
>>>> Which part of the above would "defeat the point of yank-media", and
>>>> why?
>>> yank-media presents a uniform interface to clipboard data across
>>> platforms, in principle.  This implies that there is no need to know the
>>> ugly details of how the clipboard data is to be fetched, which data
>>> types are available and which of them are bogus, etc.
>> My suggestion does not require any need to know those ugly details.
>> It just suggests to remove from the list the handlers a mode doesn't
>> want.  Removing the, say, image/png handler from the list does not
>> require any knowledge how that handler accesses the clipboard nor how
>> it extracts PNG images from the clipboard.  It just requires to know
>> the (trivial) fact that an image/png handler can interpret the
>> clipboard data as a PNG image.
>>
>> So I don't think I understand your reasoning.  What did I miss?
> That the user does want PNG images is a "soft preference."  If the
> clipboard only has image/png, the user would have the image/png data
> instead of none at all.  You offered a solution for this: bind
> yank-media--registered-handlers in a custom command but having a
> variable would make it easy for the user to have a _global_ preference
> across major-modes.
>
>>> The major-mode authors would simply write handlers for all relevant
>>> data types and leave it to the user to choose the preferred type if
>>> more than one of them is handled by the major-mode.
>> AFAIU, we were talking about situations where the major mode "knows
>> better" than the user, and doesn't want to leave the choice to users.
> No, the major-mode does not "know better" than user.  It simply wants to
> respect the "soft" preferences of the user.
>
>>> But if the major-mode authors have to cater to the user's preferred data
>>> types by looking at TARGETS in their "major-mode-yank-media" command,
>>> that defeats the abstraction yank-media provides...
>> I don't understand how.  TARGETS include stuff like image/png and
>> text/html; how does looking at that defeat any abstractions, and what
>> abstractions are those?  We cannot consider TARGETS to be an opaque
>> object anyway because then we won't be able to ask the user which of
>> the MIME types she wants to yank, nor apply any advance preferences of
>> the user.
> The MIME type the user wants to yank is asked by _yank-media_ currently.
> The major-mode has no part in this conversation, and this is exactly
> what we want to change.
>
>>> The entire point of using the library, IMHO, is to leave out this
>>> nasty business of handling the clipboard to a third party.
>> What do you mean by "handling the clipboard"?  In my mind, "handling
>> the clipboard" is what the handlers do, and my suggestion doesn't
>> change that, nor does it require any knowledge about their works.  It
>> only requires to know that each MIME type has a handler, and removing
>> that handler from the list will prevent the clipboard data from being
>> interpreted as that MIME type.
> I admit that my memory failed me when I wrote that.  I was under the
> impression that yank-media goes through a bit of effort to remove any
> nonsensical data types from TARGETS.  So, it is not nasty as I initially
> meant.
>
>>>> If Org has its own ideas about what's best for the users in some
>>>> situations, and if the users agree with that, I don't see what is
>>>> wrong with that.  The common interface presented by yank-media to
>>>> major modes is there so that major modes could use it in whichever
>>>> ways they think is best for their users.  So I see no problems in
>>>> major modes deciding to prefer some handlers over others, not in
>>>> principle.
>>> We do not disagree about this at all.  What we do disagree on is the
>>> means by which to achieve this.  If we could specify a filter function
>>> as a variable that filters out the available data types before
>>> presenting it to the user, the major-mode authors would be saved the
>>> burden of writing their yank-media-like command which requires the
>>> knowledge of obtaining TARGETS and potentially ignoring bogus types in
>>> it.
>> How will that filter function be any different from what I propose?
>> You want to filter MIME types, I suggest filtering the handler, but
>> since each handler is uniquely identified by the MIME type it handles,
>> what exactly is the big difference?
>>
>> I feel there's some gross misunderstanding here, but what is it?
> I hope it is clear now.  Two things can be achieved if we add such a
> filter function:
>
>      1. The user gets to specify her "soft" preference for available MIME
>         types.  This could be done by directly writing such a function
>         herself or use whatever mechanism the major-mode offers to
>         enforce this preference.  I say "soft" because the user does not
>         mind to use a "lesser" type if her preferred type is unavailable
>         which would not be possible by specifically registered only
>         image/USER-PREFERRED-TYPE.
>
>      2. The user gets to specify her preference globally, across
>         major-modes.  This would be hard if major-modes had to write
>         their own "yank-media" command to cater to the user's
>         preferences.
>
> The attached patch adds a variable to specify a filter function:
> yank-media-preferred-type-function.
>
>
> Without the patch applied, copying an image from Firefox and using
> yank-media in an Org buffer asks me if I want image/png or image/jpeg.
>
> With that patch applied, and after evaluating
>
>      (setq-local
>         yank-media-preferred-type-function
>         (lambda (types)
>           (if (memq 'image/png types)
>               (list 'image/png)
>             types)))
>
> in an Org buffer, or message-mode buffer, I don't get asked that
> question.  Afterwards, I copy a JPEG image using xclip then do
> yank-media. This yanks the image without asking me anything.  This would
> not be possible had Org or message-mode only registered a handler for
> image/png.
>


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

[Eli Zaretskii]

> Date: Thu, 31 Oct 2024 00:22:57 +0100
> From: Pedro <pedro@cas.cat>
> 
> The approach of this patch permits to have different yank commands with 
> different keybindings and context to respond to different needs (For the 
> things I care, I end up having two commands, one that is simple and fast 
> with the most preferred thing; and the other that gives all flexibility 
> and possibilities). So, happy to see flexibility here too.

Flexibility doesn't come for free, though: are you arguing for having
N yank-media commands, each with its own preference of media formats?
Which means the user will have to remember the preferences for each
command and allocate a separate key binding to each?  How is that a
good thing?

> It might be useful to know why this is better: it is less error prone to 
> what I have now. Let me explain this: the other day, by mistake (being 
> in a hurry) I did several screen captures and I thought I was using .png 
> (I usually pick png on the first time, and then, by frequency, it 
> appears in the first position because of the completion tool 
> (vertico/orderless ?)). But I was wrong, I took .pbm, for that case, 
> that was fine, it was notes for me, but it could be the case of having 
> screen captures with the wrong format and having difficulty to generate 
> them again. This patch and approach helps the user to avoid that risk.

I don't understand that: how is the image format of the screen capture
relevant to yanking images into an Emacs buffer?  What am I missing?

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

[pinmacs]

With the Visuwesh patch everything is fine. A good default is not 
provided, but I see that as a "second part" for the discussion, even a 
second commit, so we get some progress done.

I was just saying that as a user I prefer to define on my own my custom 
commands for flexibility, but that is a user preference, not something 
to upstream to emacs core in terms of yank-media commands. I just tell 
that, to justify, why the flexible design of having that variable, that 
as Visuwesh, allows me to do that.

Maybe I am missing too but when you choose a format, you choose how you 
store and retain that information. Depending on what you are going to do 
with that images, you might be interested in different formats. That's 
why different users might want different media types.

On 2024-10-31 09:29, Eli Zaretskii wrote:
>> Date: Thu, 31 Oct 2024 00:22:57 +0100
>> From: Pedro <pedro@cas.cat>
>>
>> The approach of this patch permits to have different yank commands with
>> different keybindings and context to respond to different needs (For the
>> things I care, I end up having two commands, one that is simple and fast
>> with the most preferred thing; and the other that gives all flexibility
>> and possibilities). So, happy to see flexibility here too.
> Flexibility doesn't come for free, though: are you arguing for having
> N yank-media commands, each with its own preference of media formats?
> Which means the user will have to remember the preferences for each
> command and allocate a separate key binding to each?  How is that a
> good thing?
>
>> It might be useful to know why this is better: it is less error prone to
>> what I have now. Let me explain this: the other day, by mistake (being
>> in a hurry) I did several screen captures and I thought I was using .png
>> (I usually pick png on the first time, and then, by frequency, it
>> appears in the first position because of the completion tool
>> (vertico/orderless ?)). But I was wrong, I took .pbm, for that case,
>> that was fine, it was notes for me, but it could be the case of having
>> screen captures with the wrong format and having difficulty to generate
>> them again. This patch and approach helps the user to avoid that risk.
> I don't understand that: how is the image format of the screen capture
> relevant to yanking images into an Emacs buffer?  What am I missing?
>

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

[Eli Zaretskii]

> Date: Thu, 31 Oct 2024 11:47:42 +0100
> From: pinmacs <pinmacs@cas.cat>
> 
> Maybe I am missing too but when you choose a format, you choose how you 
> store and retain that information. Depending on what you are going to do 
> with that images, you might be interested in different formats.

That is inaccurate: the format in which the yanked data is store in
Emacs does NOT depend on your selection.  Your selection only
determines how Emacs will fetch the data from the clipboard/selection,
and therefore also how it will interpret that data for the purpose of
inserting it into a buffer.

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

[pinmacs]

On 2024-10-31 12:16, Eli Zaretskii wrote:
>> Date: Thu, 31 Oct 2024 11:47:42 +0100
>> From: pinmacs <pinmacs@cas.cat>
>>
>> Maybe I am missing too but when you choose a format, you choose how you
>> store and retain that information. Depending on what you are going to do
>> with that images, you might be interested in different formats.
> That is inaccurate: the format in which the yanked data is store in
> Emacs does NOT depend on your selection.  Your selection only
> determines how Emacs will fetch the data from the clipboard/selection,
> and therefore also how it will interpret that data for the purpose of
> inserting it into a buffer.

Hi Eli,

Let me provide more detail.

For the way I use it through orgmode the selection determines how the 
file is stored.

If I do 2 screen captures of nature [0], and I save one of them with png 
and jpeg, this is  what appears in my orgmode buffer:

file:/path/to/emacs-orgmode-images/2024/2024-10-31_12-36-45_screenshot.png
file:/path/to/emacs-orgmode-images/2024/2024-10-31_12-36-59_screenshot.jpeg

Hence, new files where saved. And that has an impact in file size, so in 
[1] png takes 8 times more, because jpeg is able to compress better a 
natural image [2].

So me as user in two different use cases of yank-media:

- So, me in a day where I am working in IT stuff related, I might want 
to just select preferred format as png if what I capture is more 
synthetic, such as text, log errors, visual annotations on user interfaces.
- And me, in a day where I am planning a hiking, I might want to select 
jpeg as preferred format, if I am planning to go to nature, and I am 
looking on images of nature... because maybe I don't want to save full 
images, but take pieces of it

Let me know if you want the exact results attached in the mailing list, 
or you are able to reproduce yourself.

Cheers,
pinmacs

[0] 
https://en.wikipedia.org/wiki/Nature_photography#/media/File:Altja_j%C3%B5gi_Lahemaal.jpg

[1]
   [2024-10-31 Thu 12:37:08] $ du -sh 
/path/to/emacs-orgmode-images/2024/2024-10-31_12-36-45_screenshot.png
   805K 
/path/to/emacs-orgmode-images/2024/2024-10-31_12-36-45_screenshot.png
   [2024-10-31 Thu 12:37:09] $ du -sh 
/path/to/org-extra/emacs-orgmode-images/2024/2024-10-31_12-36-59_screenshot.jpeg
   101K 
/path/to/emacs-orgmode-images/2024/2024-10-31_12-36-59_screenshot.jpeg

[2] here is why https://www.techsmith.com/blog/jpg-vs-png/

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

[Eli Zaretskii]

> Date: Thu, 31 Oct 2024 12:51:04 +0100
> Cc: emacs-devel@gnu.org
> From: pinmacs <pinmacs@cas.cat>
> 
> For the way I use it through orgmode the selection determines how the 
> file is stored.

Then that is specific to Org, and is not really relevant to the issue
we are discussing here.  If Org cannot give a way to select the format
in which the image is stored, then we'd need to consider this speciall
for Org.  (And still, I don't really understand why you care about the
format Org uses to store an inline image.)

> If I do 2 screen captures of nature [0], and I save one of them with png 
> and jpeg, this is  what appears in my orgmode buffer:
> 
> file:/path/to/emacs-orgmode-images/2024/2024-10-31_12-36-45_screenshot.png
> file:/path/to/emacs-orgmode-images/2024/2024-10-31_12-36-59_screenshot.jpeg
> 
> Hence, new files where saved. And that has an impact in file size, so in 
> [1] png takes 8 times more, because jpeg is able to compress better a 
> natural image [2].

JPEG compresses better, but it also loses information.  So I think
even in this situation, PNG is a better choice I fail to understand
how the small increase in disk space could be such a serious issue
nowadays.

> So me as user in two different use cases of yank-media:
> 
> - So, me in a day where I am working in IT stuff related, I might want 
> to just select preferred format as png if what I capture is more 
> synthetic, such as text, log errors, visual annotations on user interfaces.

With my suggestion, you can still select JPEG, even if the default is
PNG.

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

[Eli Zaretskii]

> Date: Thu, 31 Oct 2024 12:20:27 +0100
> From: Cecilio Pardo <cpardo@imayhem.com>
> 
> 
> 
> On 31/10/2024 12:16, Eli Zaretskii wrote:
> >> Date: Thu, 31 Oct 2024 11:47:42 +0100
> >> From: pinmacs <pinmacs@cas.cat>
> >>
> >> Maybe I am missing too but when you choose a format, you choose how you
> >> store and retain that information. Depending on what you are going to do
> >> with that images, you might be interested in different formats.
> > 
> > That is inaccurate: the format in which the yanked data is store in
> > Emacs does NOT depend on your selection.  Your selection only
> > determines how Emacs will fetch the data from the clipboard/selection,
> > and therefore also how it will interpret that data for the purpose of
> > inserting it into a buffer.
> 
> Org-mode and html-mode save images to disk and link to them, at least 
> int the default configuration, in the format they receive them.

Then that is the problem: the format in which the inline images are
stored doesn't have to be the same format which is used to yank the
image into the buffer.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Org-mode and html-mode save images to disk and link to them, at least 
>> int the default configuration, in the format they receive them.
>
> Then that is the problem: the format in which the inline images are
> stored doesn't have to be the same format which is used to yank the
> image into the buffer.

Technically, yes. But I am pretty sure that it is almost always the case
that the format in the clipboard and the format used will be the same.

-- 
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: Cecilio Pardo <cpardo@imayhem.com>, emacs-devel@gnu.org
> Date: Thu, 31 Oct 2024 18:21:21 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Org-mode and html-mode save images to disk and link to them, at least 
> >> int the default configuration, in the format they receive them.
> >
> > Then that is the problem: the format in which the inline images are
> > stored doesn't have to be the same format which is used to yank the
> > image into the buffer.
> 
> Technically, yes. But I am pretty sure that it is almost always the case
> that the format in the clipboard and the format used will be the same.

In the general case, the yanked data will be inserted into the buffer,
not saved in some file.  So no, it is not "almost always" the case;
rather, it is almost never the case.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> In the general case, the yanked data will be inserted into the buffer,
> not saved in some file.  So no, it is not "almost always" the case;
> rather, it is almost never the case.

May you provide examples for such uses in Emacs?

-- 
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: cpardo@imayhem.com, emacs-devel@gnu.org
> Date: Thu, 31 Oct 2024 19:08:20 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In the general case, the yanked data will be inserted into the buffer,
> > not saved in some file.  So no, it is not "almost always" the case;
> > rather, it is almost never the case.
> 
> May you provide examples for such uses in Emacs?

Yanking HTML into a buffer.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > In the general case, the yanked data will be inserted into the buffer,
>> > not saved in some file.  So no, it is not "almost always" the case;
>> > rather, it is almost never the case.
>> 
>> May you provide examples for such uses in Emacs?
>
> Yanking HTML into a buffer.

Fair. What about images?

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: cpardo@imayhem.com, emacs-devel@gnu.org
> Date: Thu, 31 Oct 2024 19:42:38 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > In the general case, the yanked data will be inserted into the buffer,
> >> > not saved in some file.  So no, it is not "almost always" the case;
> >> > rather, it is almost never the case.
> >> 
> >> May you provide examples for such uses in Emacs?
> >
> > Yanking HTML into a buffer.
> 
> Fair. What about images?

An image can be yanked into a buffer for the simple purpose of showing
it, without any need to save it to a file.  In addition, I hope that
one day Emacs will be able to enhance image-save such that users could
choose in which image format to save the image.

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

[Visuwesh]

[வியாழன் அக்டோபர் 31, 2024] Pedro wrote:

> Hi Visuwesh,
>
> Thanks for the patch!! It is very useful to me.
>
> I tested it and it works as I originally expected: reduce the
> interaction to minimum: I don't need to press enter anymore! :)
>
> I also tested it with two types [1]: jpeg and png; and then you see a
> selector with just the two types you care instead of the 7 types that
> flameshot screen capture tool offers.

Thanks for the feedback.

>
> [1]
>   (setq-local
>     yank-media-preferred-type-function
>     (lambda (types)
>       (if (or
>            (memq 'image/png types)
>            (memq 'image/jpeg types))
>           (list 'image/png 'image/jpeg)
>         types)))
>

With this definition, you will be asked to choose between image/png and
image/jpeg even when the clipboard contains only image/png (or
image/jpeg).

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: Tue, 29 Oct 2024 16:59:34 +0530
> 
> > My suggestion does not require any need to know those ugly details.
> > It just suggests to remove from the list the handlers a mode doesn't
> > want.  Removing the, say, image/png handler from the list does not
> > require any knowledge how that handler accesses the clipboard nor how
> > it extracts PNG images from the clipboard.  It just requires to know
> > the (trivial) fact that an image/png handler can interpret the
> > clipboard data as a PNG image.
> >
> > So I don't think I understand your reasoning.  What did I miss?
> 
> That the user does want PNG images is a "soft preference."  If the
> clipboard only has image/png, the user would have the image/png data
> instead of none at all.  You offered a solution for this: bind
> yank-media--registered-handlers in a custom command but having a
> variable would make it easy for the user to have a _global_ preference
> across major-modes.

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

> >> The major-mode authors would simply write handlers for all relevant
> >> data types and leave it to the user to choose the preferred type if
> >> more than one of them is handled by the major-mode.
> >
> > AFAIU, we were talking about situations where the major mode "knows
> > better" than the user, and doesn't want to leave the choice to users.
> 
> No, the major-mode does not "know better" than user.

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

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

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

> > I don't understand how.  TARGETS include stuff like image/png and
> > text/html; how does looking at that defeat any abstractions, and what
> > abstractions are those?  We cannot consider TARGETS to be an opaque
> > object anyway because then we won't be able to ask the user which of
> > the MIME types she wants to yank, nor apply any advance preferences of
> > the user.
> 
> The MIME type the user wants to yank is asked by _yank-media_ currently.
> The major-mode has no part in this conversation, and this is exactly
> what we want to change.

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

> Without the patch applied, copying an image from Firefox and using
> yank-media in an Org buffer asks me if I want image/png or image/jpeg.

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

> With that patch applied, and after evaluating 
> 
>     (setq-local
>        yank-media-preferred-type-function
>        (lambda (types)
>          (if (memq 'image/png types)
>              (list 'image/png)
>            types)))
> 
> in an Org buffer, or message-mode buffer, I don't get asked that
> question.  Afterwards, I copy a JPEG image using xclip then do
> yank-media. This yanks the image without asking me anything.  This would
> not be possible had Org or message-mode only registered a handler for
> image/png.

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

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

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

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

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

[Visuwesh]

[வியாழன் அக்டோபர் 31, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: yantar92@posteo.net,  pinmacs@cas.cat,  rpluim@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Tue, 29 Oct 2024 16:59:34 +0530
>> 
>> > My suggestion does not require any need to know those ugly details.
>> > It just suggests to remove from the list the handlers a mode doesn't
>> > want.  Removing the, say, image/png handler from the list does not
>> > require any knowledge how that handler accesses the clipboard nor how
>> > it extracts PNG images from the clipboard.  It just requires to know
>> > the (trivial) fact that an image/png handler can interpret the
>> > clipboard data as a PNG image.
>> >
>> > So I don't think I understand your reasoning.  What did I miss?
>> 
>> That the user does want PNG images is a "soft preference."  If the
>> clipboard only has image/png, the user would have the image/png data
>> instead of none at all.  You offered a solution for this: bind
>> yank-media--registered-handlers in a custom command but having a
>> variable would make it easy for the user to have a _global_ preference
>> across major-modes.
>
> This (and the patch you suggest) completes the full circle of this
> discussion: it started when I said that such a global preference makes
> very little sense to me, based on my experience with yanking different
> data types in other applications.  Users have no reason for such
> preferences, as they almost never have enough reasons to prefer one
> type over the others _globally_.  The preference only makes sense in
> each specific case, and then asking the user to choose is exactly TRT,
> which we already do.

At least for images, I see a value in having a global preference.  You
also seem to agree on this point.

>> >> The major-mode authors would simply write handlers for all relevant
>> >> data types and leave it to the user to choose the preferred type if
>> >> more than one of them is handled by the major-mode.
>> >
>> > AFAIU, we were talking about situations where the major mode "knows
>> > better" than the user, and doesn't want to leave the choice to users.
>> 
>> No, the major-mode does not "know better" than user.
>
> It might, though.  And it already does, in fact: the few modes which
> support yank-media only register some of the handlers, but not others.
> Did you ask yourself why message.el registers only the handler for
> images, but not, say, for text/html?  A major mode which doesn't
> support embedded images will probably refrain from installing image/*
> handlers, etc.

Sure but it doesn't help when the major-mode can support multiple image
formats but the user wants a specific format always.  

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

I agree that it would be good to have yank-media choose the most
appropriate format itself.

>> > I don't understand how.  TARGETS include stuff like image/png and
>> > text/html; how does looking at that defeat any abstractions, and what
>> > abstractions are those?  We cannot consider TARGETS to be an opaque
>> > object anyway because then we won't be able to ask the user which of
>> > the MIME types she wants to yank, nor apply any advance preferences of
>> > the user.
>> 
>> The MIME type the user wants to yank is asked by _yank-media_ currently.
>> The major-mode has no part in this conversation, and this is exactly
>> what we want to change.
>
> Major mode _does_ have a part: it registers only the handlers it wants
> to support.  So it determines, up front, which media types will be
> available, even if more of them are in the clipboard.

I agree but its participation could be improved.  When you copy a cell
from LibreOffice's Excel clone, it puts both image/png and a TSV data
type in your clipboard.  Taking the example of Org which has a handler
registered for image/png: if it registers a handler for the TSV data
type, the user would be asked to choose between image/png and TSV when
she copies a table cell.  The intent of registering image/png is a
hindrance here.  Having a separate command for yanking a table cell
would remove the convenience of having a single command that does TRT.

>> Without the patch applied, copying an image from Firefox and using
>> yank-media in an Org buffer asks me if I want image/png or image/jpeg.
>
> Please tell me why on earth would you prefer PNG to JPEG when yanking,
> or vice versa.  The result is an image displayed in the buffer, which
> is neither PNG nor JPEG.  Why does it matter _for_you_personally_
> which intermediate format will Emacs use as part of the yanking
> process?

You answered the question yourself:

    For example, JPEG is generally inferior because it's lossy, so we
    could have that hypothetical variant of yank-media which doesn't ask
    questions to always prefer PNG to JPEG if both are possible.

>> With that patch applied, and after evaluating 
>> 
>>     (setq-local
>>        yank-media-preferred-type-function
>>        (lambda (types)
>>          (if (memq 'image/png types)
>>              (list 'image/png)
>>            types)))
>> 
>> in an Org buffer, or message-mode buffer, I don't get asked that
>> question.  Afterwards, I copy a JPEG image using xclip then do
>> yank-media. This yanks the image without asking me anything.  This would
>> not be possible had Org or message-mode only registered a handler for
>> image/png.
>
> If we want to avoid the question when several image formats are
> available, we could teach Org, or Emacs in general, which formats to
> prefer.  For example, JPEG is generally inferior because it's lossy,
> so we could have that hypothetical variant of yank-media which doesn't
> ask questions to always prefer PNG to JPEG if both are possible.  This
> is IMO better than asking the users to decide that for Emacs.

I agree, but can we, at least, agree that it should be easy to override
it completely?  What do you think about adding a patch like I proposed
but also having a "sensible" default definition of
yank-media-preferred-type-function? (for some definition of sensible.)

> Anyway, since with this message we've made a full circle, let me
> summarize my opinions on this:
>
>   . I think we should add to Emacs rules for preferring one media
>     format over the others when several are available and supported
>   . Such rules should be customized by major modes based on their
>     features and preferences (e.g., a mode that has no support for
>     faces might prefer plain text to other textual formats)

(1) and (2) would be best done with the help of user feedback.  A patch
like the one I proposed would help to kick-start it.  IMO, coming up
with such rules is a long game that requires user feedback (like the one
that started this whole thread).  Due to the number of users and its
relevance, Org is a good ground for obtaining user feedback on this
subject.

>   . I think we should have a variant of yank-media that yanks "the
>     best" of the available formats without asking, based on the above
>     rules

I like your idea of reusing C-u for this.

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

The built-in preference rules is already a global "preference" from
where I stand.  Only that, the OP wanted control over these rules.

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: Thu, 31 Oct 2024 14:16:07 +0530
> 
> > This (and the patch you suggest) completes the full circle of this
> > discussion: it started when I said that such a global preference makes
> > very little sense to me, based on my experience with yanking different
> > data types in other applications.  Users have no reason for such
> > preferences, as they almost never have enough reasons to prefer one
> > type over the others _globally_.  The preference only makes sense in
> > each specific case, and then asking the user to choose is exactly TRT,
> > which we already do.
> 
> At least for images, I see a value in having a global preference.  You
> also seem to agree on this point.

I agree with having an Emacs-wide preference rule, not with asking
users to define those preferences.

> > Major mode _does_ have a part: it registers only the handlers it wants
> > to support.  So it determines, up front, which media types will be
> > available, even if more of them are in the clipboard.
> 
> I agree but its participation could be improved.  When you copy a cell
> from LibreOffice's Excel clone, it puts both image/png and a TSV data
> type in your clipboard.  Taking the example of Org which has a handler
> registered for image/png: if it registers a handler for the TSV data
> type, the user would be asked to choose between image/png and TSV when
> she copies a table cell.  The intent of registering image/png is a
> hindrance here.  Having a separate command for yanking a table cell
> would remove the convenience of having a single command that does TRT.

The default yank-media (e.g., with an argument) should yank the TSV
format, and only offer the PNG format as an option if the user for
some reason wants that.

> > Please tell me why on earth would you prefer PNG to JPEG when yanking,
> > or vice versa.  The result is an image displayed in the buffer, which
> > is neither PNG nor JPEG.  Why does it matter _for_you_personally_
> > which intermediate format will Emacs use as part of the yanking
> > process?
> 
> You answered the question yourself:
> 
>     For example, JPEG is generally inferior because it's lossy, so we
>     could have that hypothetical variant of yank-media which doesn't ask
>     questions to always prefer PNG to JPEG if both are possible.

That is not something we should ask users to do, IMO.

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

Override how and for what purpose?  If we have a command which asks
the user to select one format from a list of available ones, the
general preference can always be overridden, just on a case by case
basis.  Why do we also need to override it globally?

> > Anyway, since with this message we've made a full circle, let me
> > summarize my opinions on this:
> >
> >   . I think we should add to Emacs rules for preferring one media
> >     format over the others when several are available and supported
> >   . Such rules should be customized by major modes based on their
> >     features and preferences (e.g., a mode that has no support for
> >     faces might prefer plain text to other textual formats)
> 
> (1) and (2) would be best done with the help of user feedback.

Feedback is always welcome, but I submit that we can formulate a very
good approximation for the rules without any feedback.

> IMO, coming up with such rules is a long game that requires user
> feedback (like the one that started this whole thread).

No, I think it is actually quite simple and will be quite close to the
optimum the first time we come up with such rules.  It is possible
that a major mode will want to override the rules, for its own
reasons, but that should also be very obvious for each mode.

> >   . I think we should have a variant of yank-media that yanks "the
> >     best" of the available formats without asking, based on the above
> >     rules
> 
> I like your idea of reusing C-u for this.
> 
> > If after all of this people still want a global "preference", I won't
> > mount the barricades to fight that, although, as I explained, such a
> > global preference makes little sense to me, and sounds like an
> > inferior replacement for the missing built-in preference rules I think
> > we should have.
> 
> The built-in preference rules is already a global "preference" from
> where I stand.  Only that, the OP wanted control over these rules.

And I'm saying that I don't understand why users would need such
control, in addition to being able to select a format in each case.

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

[Visuwesh]

[வியாழன் அக்டோபர் 31, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: yantar92@posteo.net,  pinmacs@cas.cat,  rpluim@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Thu, 31 Oct 2024 14:16:07 +0530
>> 
>> > This (and the patch you suggest) completes the full circle of this
>> > discussion: it started when I said that such a global preference makes
>> > very little sense to me, based on my experience with yanking different
>> > data types in other applications.  Users have no reason for such
>> > preferences, as they almost never have enough reasons to prefer one
>> > type over the others _globally_.  The preference only makes sense in
>> > each specific case, and then asking the user to choose is exactly TRT,
>> > which we already do.
>> 
>> At least for images, I see a value in having a global preference.  You
>> also seem to agree on this point.
>
> I agree with having an Emacs-wide preference rule, not with asking
> users to define those preferences.
>
>> > Major mode _does_ have a part: it registers only the handlers it wants
>> > to support.  So it determines, up front, which media types will be
>> > available, even if more of them are in the clipboard.
>> 
>> I agree but its participation could be improved.  When you copy a cell
>> from LibreOffice's Excel clone, it puts both image/png and a TSV data
>> type in your clipboard.  Taking the example of Org which has a handler
>> registered for image/png: if it registers a handler for the TSV data
>> type, the user would be asked to choose between image/png and TSV when
>> she copies a table cell.  The intent of registering image/png is a
>> hindrance here.  Having a separate command for yanking a table cell
>> would remove the convenience of having a single command that does TRT.
>
> The default yank-media (e.g., with an argument) should yank the TSV
> format, and only offer the PNG format as an option if the user for
> some reason wants that.
>
>> > Please tell me why on earth would you prefer PNG to JPEG when yanking,
>> > or vice versa.  The result is an image displayed in the buffer, which
>> > is neither PNG nor JPEG.  Why does it matter _for_you_personally_
>> > which intermediate format will Emacs use as part of the yanking
>> > process?
>> 
>> You answered the question yourself:
>> 
>>     For example, JPEG is generally inferior because it's lossy, so we
>>     could have that hypothetical variant of yank-media which doesn't ask
>>     questions to always prefer PNG to JPEG if both are possible.
>
> That is not something we should ask users to do, IMO.
>
>> > If we want to avoid the question when several image formats are
>> > available, we could teach Org, or Emacs in general, which formats to
>> > prefer.  For example, JPEG is generally inferior because it's lossy,
>> > so we could have that hypothetical variant of yank-media which doesn't
>> > ask questions to always prefer PNG to JPEG if both are possible.  This
>> > is IMO better than asking the users to decide that for Emacs.
>> 
>> I agree, but can we, at least, agree that it should be easy to override
>> it completely?
>
> Override how and for what purpose?  If we have a command which asks
> the user to select one format from a list of available ones, the
> general preference can always be overridden, just on a case by case
> basis.  Why do we also need to override it globally?
>
>> > Anyway, since with this message we've made a full circle, let me
>> > summarize my opinions on this:
>> >
>> >   . I think we should add to Emacs rules for preferring one media
>> >     format over the others when several are available and supported
>> >   . Such rules should be customized by major modes based on their
>> >     features and preferences (e.g., a mode that has no support for
>> >     faces might prefer plain text to other textual formats)
>> 
>> (1) and (2) would be best done with the help of user feedback.
>
> Feedback is always welcome, but I submit that we can formulate a very
> good approximation for the rules without any feedback.
>
>> IMO, coming up with such rules is a long game that requires user
>> feedback (like the one that started this whole thread).
>
> No, I think it is actually quite simple and will be quite close to the
> optimum the first time we come up with such rules.  It is possible
> that a major mode will want to override the rules, for its own
> reasons, but that should also be very obvious for each mode.
>
>> >   . I think we should have a variant of yank-media that yanks "the
>> >     best" of the available formats without asking, based on the above
>> >     rules
>> 
>> I like your idea of reusing C-u for this.
>> 
>> > If after all of this people still want a global "preference", I won't
>> > mount the barricades to fight that, although, as I explained, such a
>> > global preference makes little sense to me, and sounds like an
>> > inferior replacement for the missing built-in preference rules I think
>> > we should have.
>> 
>> The built-in preference rules is already a global "preference" from
>> where I stand.  Only that, the OP wanted control over these rules.
>
> And I'm saying that I don't understand why users would need such
> control, in addition to being able to select a format in each case.

OK, I think I finally understand your stance: we let yank-media pick the
best format out of all in the clipboard based on rules that a major-mode
can tweak.  Apart from this, we also have C-u or somesuch that asks the
user to select the data type instead of auto-selecting it.  Since the
C-u is good enough to override a case-by-case basis, you do not see
value in having a defcustom to let the user customise the selection
rules for the best data type, correct?

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: Fri, 01 Nov 2024 10:50:43 +0530
> 
> OK, I think I finally understand your stance: we let yank-media pick the
> best format out of all in the clipboard based on rules that a major-mode
> can tweak.  Apart from this, we also have C-u or somesuch that asks the
> user to select the data type instead of auto-selecting it.  Since the
> C-u is good enough to override a case-by-case basis, you do not see
> value in having a defcustom to let the user customise the selection
> rules for the best data type, correct?

Yes.  Thanks for a concise summary.

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

[Ihor Radchenko]

Visuwesh <visuweshm@gmail.com> writes:

>> And I'm saying that I don't understand why users would need such
>> control, in addition to being able to select a format in each case.
>
> OK, I think I finally understand your stance: we let yank-media pick the
> best format out of all in the clipboard based on rules that a major-mode
> can tweak.  Apart from this, we also have C-u or somesuch that asks the
> user to select the data type instead of auto-selecting it.  Since the
> C-u is good enough to override a case-by-case basis, you do not see
> value in having a defcustom to let the user customise the selection
> rules for the best data type, correct?

So, what will be the plan here? A patch?

-- 
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: Eli Zaretskii <eliz@gnu.org>, pinmacs@cas.cat, rpluim@gmail.com,
>  emacs-devel@gnu.org
> Date: Sun, 03 Nov 2024 17:19:26 +0000
> 
> Visuwesh <visuweshm@gmail.com> writes:
> 
> >> And I'm saying that I don't understand why users would need such
> >> control, in addition to being able to select a format in each case.
> >
> > OK, I think I finally understand your stance: we let yank-media pick the
> > best format out of all in the clipboard based on rules that a major-mode
> > can tweak.  Apart from this, we also have C-u or somesuch that asks the
> > user to select the data type instead of auto-selecting it.  Since the
> > C-u is good enough to override a case-by-case basis, you do not see
> > value in having a defcustom to let the user customise the selection
> > rules for the best data type, correct?
> 
> So, what will be the plan here? A patch?

Eventually, I hope so, yes.

What other kinds of plans do we have in Emacs?

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

[Visuwesh]

[ஞாயிறு நவம்பர் 03, 2024] Ihor Radchenko wrote:

> Visuwesh <visuweshm@gmail.com> writes:
>
>>> And I'm saying that I don't understand why users would need such
>>> control, in addition to being able to select a format in each case.
>>
>> OK, I think I finally understand your stance: we let yank-media pick the
>> best format out of all in the clipboard based on rules that a major-mode
>> can tweak.  Apart from this, we also have C-u or somesuch that asks the
>> user to select the data type instead of auto-selecting it.  Since the
>> C-u is good enough to override a case-by-case basis, you do not see
>> value in having a defcustom to let the user customise the selection
>> rules for the best data type, correct?
>
> So, what will be the plan here? A patch?

I just want to inform that I probably won't be able to get to writing a
patch until mid December since I hardly have time with my semester end
nearing.

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

[Ihor Radchenko]

Visuwesh <visuweshm@gmail.com> writes:
>> So, what will be the plan here? A patch?
>
> I just want to inform that I probably won't be able to get to writing a
> patch until mid December since I hardly have time with my semester end
> nearing.

Thanks for the update!
I am happy to hear that there are no more conceptual obstacles to moving
this forward other than simple waiting.

-- 
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: Eli Zaretskii <eliz@gnu.org>, pinmacs@cas.cat, rpluim@gmail.com,
>  emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 20:03:55 +0000
> 
> I am happy to hear that there are no more conceptual obstacles to moving
> this forward other than simple waiting.

Actually, I think that this area is still not clear conceptually.
(Which is not surprising, given that it is a very recent addition to
Emacs.)  One aspect that bugs me is that we have two separate commands
for yanking: one for textual data, the other for everything else.  Not
only is this conceptually problematic, it also poses UI problems for
formats that can be yanked either as some textual or some non-textual
forms.  One simple example is yanking formatted text as HTML or as an
image.

Another conceptual issue is what would be those "rules" for preferring
one format over the others, and how will they depend on major-mode.

Yet another issue is in what modes to set up yank-media handlers.
Right now, we have a very small number of such modes, which is in
stark contrast to C-y which is supported basically everywhere.  One
could ask why shouldn't we have yank-media handlers available in all
modes as well.

And I'm sure there are other issues to ponder.  We are just beginning
to explore this area, so it is expected to have these questions.

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

[Visuwesh]

[திங்கள் நவம்பர் 04, 2024] Visuwesh wrote:

To recap,

The OP asked for a way to choose a specific image type out of the
multiple types available in their clipboard.  We decided that Emacs
should auto-select the best type itself and have a way for major-modes
to customise this selection process.  Auto-selection should also be
skipped with a prefix arg.

> [ஞாயிறு நவம்பர் 03, 2024] Ihor Radchenko wrote:
>
>> Visuwesh <visuweshm@gmail.com> writes:
>>
>>>> And I'm saying that I don't understand why users would need such
>>>> control, in addition to being able to select a format in each case.
>>>
>>> OK, I think I finally understand your stance: we let yank-media pick the
>>> best format out of all in the clipboard based on rules that a major-mode
>>> can tweak.  Apart from this, we also have C-u or somesuch that asks the
>>> user to select the data type instead of auto-selecting it.  Since the
>>> C-u is good enough to override a case-by-case basis, you do not see
>>> value in having a defcustom to let the user customise the selection
>>> rules for the best data type, correct?
>>
>> So, what will be the plan here? A patch?
>
> I just want to inform that I probably won't be able to get to writing a
> patch until mid December since I hardly have time with my semester end
> nearing.

Here's the promised patch (I can create a bug report if that is
preferred):

diff --git a/lisp/yank-media.el b/lisp/yank-media.el
index 17981c37c0e..a5ad913c24a 100644
--- a/lisp/yank-media.el
+++ b/lisp/yank-media.el
@@ -29,19 +29,49 @@
 
 (defvar yank-media--registered-handlers nil)
 
+(defvar yank-media-autoselect-function #'yank-media-autoselect-function
+  "Function to auto select the best mime type when many are available.
+The function is called with a list of mime types that have handler in
+the current buffer, and should return the type to use or nil if no
+preferred type is found.")
+
+(defun yank-media-autoselect-function (mimetypes)
+  (cond
+   ;; Check first since LibreOffice also puts a PNG image in the
+   ;; clipboard when a table cell is copied.
+   ((memq 'application/x-libreoffice-tsvc mimetypes)
+    'application/x-libreoffice-tsvc)
+   ;; Give PNG more priority.
+   ((memq 'image/png mimetypes)
+    'image/png)
+   ((memq 'image/jpeg mimetypes)
+    'image/jpeg)
+   ;; These are files copied/cut to the clipboard from a file manager.
+   ((seq-find (lambda (type)
+                (string-match-p "x-special/\\(gnome\|KDE\|mate\)-files"
+                                (symbol-name type)))
+              mimetypes))
+   ;; FIXME: We should have a way to handle text/rtf.
+   ((memq 'text/html mimetypes)
+    'text/html)))
+
 ;;;###autoload
-(defun yank-media ()
+(defun yank-media (&optional noselect)
   "Yank media (images, HTML and the like) from the clipboard.
 This command depends on the current major mode having support for
 accepting the media type.  The mode has to register itself using
 the `yank-media-handler' mechanism.
+Optional argument NOSELECT non-nil (interactively, with a prefix
+argument) means to skip auto-selecting the best mimetype and ask
+for the media type to use when multiple are available.
 
 Also see `yank-media-types' for a command that lets you explore
 all the different selection types."
-  (interactive)
+  (interactive "P")
   (unless yank-media--registered-handlers
     (user-error "The `%s' mode hasn't registered any handlers" major-mode))
-  (let ((all-types nil))
+  (let ((all-types nil)
+        pref-type)
     (pcase-dolist (`(,handled-type . ,handler)
                    yank-media--registered-handlers)
       (dolist (type (yank-media--find-matching-media handled-type))
@@ -49,18 +79,27 @@ 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.
+    (setq pref-type (and (null noselect)
+                         (funcall yank-media-autoselect-function
+                                  (mapcar #'car all-types))))
+    (cond
+     ;; We have a preferred mime type so use it unconditionally.
+     ((and (null noselect) pref-type)
+      (funcall (cdr (assq pref-type all-types)) pref-type
+               (yank-media--get-selection pref-type)))
+     ;; The user chose to not autoselet and there's just a single type,
+     ;; just call the handler.
+     ((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.
+     (t
       (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))))))
+                 type (yank-media--get-selection type)))))))
 
 (defun yank-media--find-matching-media (handled-type)
   (seq-filter

As planned, yank-media auto-selects the best media type out of the
available types by default.  This auto-selection can be skipped by
giving a prefix arg.  Some details about the selection process itself:

  1. The autoselect function can return only one preferred type.
  2. There is no user option to control this selection process.  I
     cannot envision such an option myself.  Major mode authors can
     control the selection rules by using add-function (like they
     already do with e.g., filter-buffer-substring-function):

        (add-function :before/:after/:around/...
                      (local 'yank-media-autoselect-function)
                      #'major-mode-ymaf)

     An informed user could do the same if she desires.
  3. The autoselect function _can_ return nil.  If it does, then we
     proceed as if the prefix arg was given.  This makes sense to me
     since we cannot hope to be exhaustive since the mime type can be
     _anything_.  For e.g., Avogadro puts chemical/x-mdl-molfile when
     you select and copy atoms but I doubt many Emacs user would ever
     come across such a type in their clipboard.  So it is best we fall
     over to the NOSELECT=t when the autoselect function returns nil
     instead of signalling an error.
  4. We select application/x-libreoffice-tsvc first since LibreOffice
     also puts image/png when you copy table cell(s).
  5. We prefer PNG images over other types.
  6. We prefer text/html but I believe the plan is to eventually prefer
     text/rtf?

Now some questions:

  1. Should we allow the autoselect function to return _multiple_
     preferred types?
  2. Should we prefer image/svg over image/png and image/jpeg?  Should
     we prefer it over image/jpeg at least?  Or do we leave it to the
     major-mode to take care of this (e.g., as in Robert's example)?
  3. We prefer images over files cut/copied to the clipboard.  I don't
     know if any software puts both image/png and
     x-special/gnome-copied-files to the clipboard.  If it does, which
     do we prefer?  The list of file:// links or raw image/png data?
  4. The mimetype used for cut/copied files only works in Linux
     environments.  If other platforms can present such file:// links in
     the clipboard and Emacs supports it, we would need to add it to the
     list too.

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,  rpluim@gmail.com,
>   emacs-devel@gnu.org
> Date: Thu, 12 Dec 2024 21:48:30 +0530
> 
> >> So, what will be the plan here? A patch?
> >
> > I just want to inform that I probably won't be able to get to writing a
> > patch until mid December since I hardly have time with my semester end
> > nearing.
> 
> Here's the promised patch (I can create a bug report if that is
> preferred):

I think you should.

Any objections or comments/suggestions for the patch?  Should we
install it?

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> Any objections or comments/suggestions for the patch?  Should we
> install it?

The only comment is that leaving an option to return a list of types
rather than only a single type will make things more flexible.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
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

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