* yank-media: allow users to limit image types that can be inserted @ 2024-09-22 16:53 pinmacs 2024-09-23 11:20 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: pinmacs @ 2024-09-22 16:53 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-22 16:53 yank-media: allow users to limit image types that can be inserted pinmacs @ 2024-09-23 11:20 ` Eli Zaretskii 2024-09-23 13:46 ` Visuwesh 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 11:20 UTC (permalink / raw) To: pinmacs; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 11:20 ` Eli Zaretskii @ 2024-09-23 13:46 ` Visuwesh 2024-09-23 14:30 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Visuwesh @ 2024-09-23 13:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pinmacs, emacs-devel [திங்கள் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 13:46 ` Visuwesh @ 2024-09-23 14:30 ` Eli Zaretskii 2024-09-23 15:06 ` Visuwesh 2024-09-23 15:09 ` Robert Pluim 0 siblings, 2 replies; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 14:30 UTC (permalink / raw) To: Visuwesh; +Cc: pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 14:30 ` Eli Zaretskii @ 2024-09-23 15:06 ` Visuwesh 2024-09-23 15:48 ` Eli Zaretskii 2024-09-23 15:09 ` Robert Pluim 1 sibling, 1 reply; 34+ messages in thread From: Visuwesh @ 2024-09-23 15:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pinmacs, emacs-devel [திங்கள் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 15:06 ` Visuwesh @ 2024-09-23 15:48 ` Eli Zaretskii 0 siblings, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 15:48 UTC (permalink / raw) To: Visuwesh; +Cc: pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 14:30 ` Eli Zaretskii 2024-09-23 15:06 ` Visuwesh @ 2024-09-23 15:09 ` Robert Pluim 2024-09-23 15:14 ` Visuwesh 2024-09-23 15:54 ` Eli Zaretskii 1 sibling, 2 replies; 34+ messages in thread From: Robert Pluim @ 2024-09-23 15:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Visuwesh, pinmacs, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 15:09 ` Robert Pluim @ 2024-09-23 15:14 ` Visuwesh 2024-09-23 15:20 ` Robert Pluim 2024-09-23 15:58 ` Eli Zaretskii 2024-09-23 15:54 ` Eli Zaretskii 1 sibling, 2 replies; 34+ messages in thread From: Visuwesh @ 2024-09-23 15:14 UTC (permalink / raw) To: Robert Pluim; +Cc: Eli Zaretskii, pinmacs, emacs-devel [திங்கள் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 15:14 ` Visuwesh @ 2024-09-23 15:20 ` Robert Pluim 2024-09-23 15:58 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Robert Pluim @ 2024-09-23 15:20 UTC (permalink / raw) To: Visuwesh; +Cc: Eli Zaretskii, pinmacs, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 15:14 ` Visuwesh 2024-09-23 15:20 ` Robert Pluim @ 2024-09-23 15:58 ` Eli Zaretskii 2024-09-24 5:00 ` Visuwesh 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 15:58 UTC (permalink / raw) To: Visuwesh; +Cc: rpluim, pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 15:58 ` Eli Zaretskii @ 2024-09-24 5:00 ` Visuwesh 2024-09-24 5:10 ` Visuwesh 2024-09-24 11:57 ` Eli Zaretskii 0 siblings, 2 replies; 34+ messages in thread From: Visuwesh @ 2024-09-24 5:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rpluim, pinmacs, emacs-devel [திங்கள் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 5:00 ` Visuwesh @ 2024-09-24 5:10 ` Visuwesh 2024-09-24 11:57 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Visuwesh @ 2024-09-24 5:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rpluim, pinmacs, emacs-devel [செவ்வாய் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 5:00 ` Visuwesh 2024-09-24 5:10 ` Visuwesh @ 2024-09-24 11:57 ` Eli Zaretskii 2024-09-24 12:42 ` Visuwesh 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-24 11:57 UTC (permalink / raw) To: Visuwesh; +Cc: rpluim, pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 11:57 ` Eli Zaretskii @ 2024-09-24 12:42 ` Visuwesh 0 siblings, 0 replies; 34+ messages in thread From: Visuwesh @ 2024-09-24 12:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rpluim, pinmacs, emacs-devel [செவ்வாய் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 15:09 ` Robert Pluim 2024-09-23 15:14 ` Visuwesh @ 2024-09-23 15:54 ` Eli Zaretskii 2024-09-23 16:10 ` Robert Pluim 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 15:54 UTC (permalink / raw) To: Robert Pluim; +Cc: visuweshm, pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 15:54 ` Eli Zaretskii @ 2024-09-23 16:10 ` Robert Pluim 2024-09-23 16:34 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Robert Pluim @ 2024-09-23 16:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, pinmacs, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 16:10 ` Robert Pluim @ 2024-09-23 16:34 ` Eli Zaretskii 2024-09-23 18:00 ` pinmacs 2024-09-23 18:11 ` Eli Zaretskii 0 siblings, 2 replies; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 16:34 UTC (permalink / raw) To: Robert Pluim; +Cc: visuweshm, pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 16:34 ` Eli Zaretskii @ 2024-09-23 18:00 ` pinmacs 2024-09-23 18:35 ` Eli Zaretskii 2024-09-23 18:11 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: pinmacs @ 2024-09-23 18:00 UTC (permalink / raw) To: Eli Zaretskii, Robert Pluim; +Cc: visuweshm, emacs-devel 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. > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 18:00 ` pinmacs @ 2024-09-23 18:35 ` Eli Zaretskii 2024-09-23 20:45 ` Pedro ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 18:35 UTC (permalink / raw) To: pinmacs; +Cc: rpluim, visuweshm, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 18:35 ` Eli Zaretskii @ 2024-09-23 20:45 ` Pedro 2024-09-23 21:08 ` pinmacs 2024-09-24 5:08 ` Visuwesh 2 siblings, 0 replies; 34+ messages in thread From: Pedro @ 2024-09-23 20:45 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 18:35 ` Eli Zaretskii 2024-09-23 20:45 ` Pedro @ 2024-09-23 21:08 ` pinmacs 2024-09-24 8:15 ` Robert Pluim 2024-09-24 11:30 ` Eli Zaretskii 2024-09-24 5:08 ` Visuwesh 2 siblings, 2 replies; 34+ messages in thread From: pinmacs @ 2024-09-23 21:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rpluim, visuweshm, emacs-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 21:08 ` pinmacs @ 2024-09-24 8:15 ` Robert Pluim 2024-09-24 11:30 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Robert Pluim @ 2024-09-24 8:15 UTC (permalink / raw) To: pinmacs; +Cc: Eli Zaretskii, visuweshm, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 21:08 ` pinmacs 2024-09-24 8:15 ` Robert Pluim @ 2024-09-24 11:30 ` Eli Zaretskii 2024-09-24 12:18 ` Robert Pluim 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-24 11:30 UTC (permalink / raw) To: pinmacs; +Cc: rpluim, visuweshm, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 11:30 ` Eli Zaretskii @ 2024-09-24 12:18 ` Robert Pluim 2024-09-24 13:08 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Robert Pluim @ 2024-09-24 12:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pinmacs, visuweshm, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 12:18 ` Robert Pluim @ 2024-09-24 13:08 ` Eli Zaretskii 2024-09-24 13:38 ` Visuwesh 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-24 13:08 UTC (permalink / raw) To: Robert Pluim; +Cc: pinmacs, visuweshm, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 13:08 ` Eli Zaretskii @ 2024-09-24 13:38 ` Visuwesh 2024-09-24 13:50 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Visuwesh @ 2024-09-24 13:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Robert Pluim, pinmacs, emacs-devel [செவ்வாய் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 13:38 ` Visuwesh @ 2024-09-24 13:50 ` Eli Zaretskii 0 siblings, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2024-09-24 13:50 UTC (permalink / raw) To: Visuwesh; +Cc: rpluim, pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 18:35 ` Eli Zaretskii 2024-09-23 20:45 ` Pedro 2024-09-23 21:08 ` pinmacs @ 2024-09-24 5:08 ` Visuwesh 2024-09-24 12:00 ` Eli Zaretskii 2 siblings, 1 reply; 34+ messages in thread From: Visuwesh @ 2024-09-24 5:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pinmacs, rpluim, emacs-devel [திங்கள் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 5:08 ` Visuwesh @ 2024-09-24 12:00 ` Eli Zaretskii 2024-09-24 12:50 ` Visuwesh 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-24 12:00 UTC (permalink / raw) To: Visuwesh; +Cc: pinmacs, rpluim, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 12:00 ` Eli Zaretskii @ 2024-09-24 12:50 ` Visuwesh 2024-09-24 13:23 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Visuwesh @ 2024-09-24 12:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pinmacs, rpluim, emacs-devel [செவ்வாய் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 12:50 ` Visuwesh @ 2024-09-24 13:23 ` Eli Zaretskii 2024-09-24 13:37 ` Visuwesh 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-24 13:23 UTC (permalink / raw) To: Visuwesh; +Cc: pinmacs, rpluim, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-24 13:23 ` Eli Zaretskii @ 2024-09-24 13:37 ` Visuwesh 0 siblings, 0 replies; 34+ messages in thread From: Visuwesh @ 2024-09-24 13:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pinmacs, rpluim, emacs-devel [செவ்வாய் செப்டம்பர் 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 16:34 ` Eli Zaretskii 2024-09-23 18:00 ` pinmacs @ 2024-09-23 18:11 ` Eli Zaretskii 2024-09-24 8:38 ` Robert Pluim 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2024-09-23 18:11 UTC (permalink / raw) To: rpluim; +Cc: visuweshm, pinmacs, emacs-devel > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: yank-media: allow users to limit image types that can be inserted 2024-09-23 18:11 ` Eli Zaretskii @ 2024-09-24 8:38 ` Robert Pluim 0 siblings, 0 replies; 34+ messages in thread From: Robert Pluim @ 2024-09-24 8:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, pinmacs, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2024-09-24 13:50 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-09-22 16:53 yank-media: allow users to limit image types that can be inserted pinmacs 2024-09-23 11:20 ` Eli Zaretskii 2024-09-23 13:46 ` Visuwesh 2024-09-23 14:30 ` Eli Zaretskii 2024-09-23 15:06 ` Visuwesh 2024-09-23 15:48 ` Eli Zaretskii 2024-09-23 15:09 ` Robert Pluim 2024-09-23 15:14 ` Visuwesh 2024-09-23 15:20 ` Robert Pluim 2024-09-23 15:58 ` Eli Zaretskii 2024-09-24 5:00 ` Visuwesh 2024-09-24 5:10 ` Visuwesh 2024-09-24 11:57 ` Eli Zaretskii 2024-09-24 12:42 ` Visuwesh 2024-09-23 15:54 ` Eli Zaretskii 2024-09-23 16:10 ` Robert Pluim 2024-09-23 16:34 ` Eli Zaretskii 2024-09-23 18:00 ` pinmacs 2024-09-23 18:35 ` Eli Zaretskii 2024-09-23 20:45 ` Pedro 2024-09-23 21:08 ` pinmacs 2024-09-24 8:15 ` Robert Pluim 2024-09-24 11:30 ` Eli Zaretskii 2024-09-24 12:18 ` Robert Pluim 2024-09-24 13:08 ` Eli Zaretskii 2024-09-24 13:38 ` Visuwesh 2024-09-24 13:50 ` Eli Zaretskii 2024-09-24 5:08 ` Visuwesh 2024-09-24 12:00 ` Eli Zaretskii 2024-09-24 12:50 ` Visuwesh 2024-09-24 13:23 ` Eli Zaretskii 2024-09-24 13:37 ` Visuwesh 2024-09-23 18:11 ` Eli Zaretskii 2024-09-24 8:38 ` Robert Pluim
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).