org-mac-image-paste — Paste images and cropped PDF clips directly into org files (Mac only)

[org-mac-image-paste](https://github.com/jdtsmith/org-mac-image-paste) — Paste images and cropped PDF clips directly into org files. **emacs-mac only** I've been trying to switch to Org-mode for note-taking, coming from Evernote, Notes.app, etc. I love the organizational power and security of plain text, but one thing I could never understand: *why can't I just directly paste image/PDF data into an org file*? I use this literally all the time, accumulating graphs, formulae, small screenshots, images from papers, websites, manuscripts, etc. The other key feature I needed was that cropped PDF data remained exactly that: a PDF file on disk. This is because I may later use it in talks, white-papers, etc., where preserving the vector quality is crucial. So, after some time trying (and failing) to convince myself such functionality must already exist, I wrote up a small package. Note that it unfortunately works only with the excellent [emacs-mac](https://bitbucket.org/mituharu/emacs-mac/) variant, which provides (some) information about image data on the clipboard. I'm hopeful similar more general functionality could come to emacs/org in the future.

It's so odd that the `image-io` stuff is only in the emacs-mac fork! Great idea though, wondered how to get this myself.

This is really great!

Just added simple drag-and-drop support for cropped PDF/HDPi PNG as well.

Emacs 29 comes with "yank-media" command, and message-mode already supports it. It is now up to the org maintainers to support yank-media. ** New command 'yank-media'. This command supports yanking non-plain-text media like images and HTML from other applications into Emacs. It is only supported in modes that have registered support for it, and only on capable platforms. EDIT: See https://lars.ingebrigtsen.no/2021/11/08/copying-media-to-emacs/

Excellent news, thanks. Definitely agree with the sentiment that this is \~3 decades overdue ;). I bet this will migrate into org. I do wonder why there is a separate command though? My little package allows just yanking whatever is on the kill ring via the clipboard into org. Right now, if image data is on the clipboard, and you attempt to yank (on non emacs-mac versions), it just reports `Kill ring is empty`. So it might be reasonable to overlay yank to do the job of 'yank-media', and just replace this message with, e.g. `No handler for yanked image data` or similar if a mode hasn't registered itself as supporting images. I'm not sure how it's handled on X11, but on MacOS the clipboard holds various versions of the same thing depending on image data. For example, when copying an image from a browser window: % osascript -e 'clipboard info' TIFF picture, 10262, URL, 27, «class urln», 9, «class utf8», 27, «class rtfd», 8528, «class weba», 7693, «class HTML», 1375, «class 8BPS», 9341, GIF picture, 2639, «class jp2 », 3803, JPEG picture, 2184, «class PNGf», 5388, «class BMP », 6966, «class TPIC», 6682, «class ut16», 56, string, 27, Unicode text, 54 Apps have to decide which of these many versions to "ask for".

> I do wonder why there is a separate command though? My little > package allows just yanking whatever is on the kill ring via the > clipboard into org. I can't try your package but does it handle any arbitrary type of data tho? I can already see myself hating such a change if the major mode decides that it is a good idea if, e.g., richly formatted text should pasted with the proper formatting. I dislike that notion strongly. But see this msg in emacs-devel https://yhetil.org/emacs-devel/878ry0kt2h.fsf@gnus.org/. Lars writes, > \> Also, should this be bound to a key? Perhaps even C-y? > > There are so few modes that support media yanking that it's premature to > put it on any key, I think. And certainly not on `C-y' -- that would > break all sorts of things, I think. (People marking text in a web > browser and hitting `C-y' in a html-mode buffer still expect to get just > the plain text, while `yank-media' will give them more options, like > text/html.) I agree with the sentiment, and I would think most Emacs user would prefer explicitly asking to do the thing instead of trying to be "smart."

>does it handle any arbitrary type of data tho? No, it's specifically and exclusively for image types and PDF on the clipboard. Other data gets passed through to normal `org-yank`. >richly formatted text should pasted with the proper formatting. I dislike that notion strongly. ... most Emacs user would prefer explicitly asking to do the thing instead of trying to be "smart." This package is only operational when a yank would otherwise say (erroneously) `Kill ring is empty`. IMO, not claiming the kill ring is empty after an explicit copy shouldn't really count as "smart" :). What's funny is how I discovered that emacs-mac actually can paste image data, but not backed by a file, and TIFF format only (hence a bit useless for org mode). I simply expected it to "just work" in org mode, blithely pasted an image in, and was very surprised to find this feature missing. But I agree with you on the issue of ambiguous cases like HTML, etc. A corner case the package does address is when you "Copy Image" from a browser. In addition to the bitmap image data, the URL of the image (or whatever it links to) is also present on the clipboard (at least on Mac). So what would be the least surprising thing to do there? Given that I could have opted to "Copy Image Link", I think inserting the image data is still obviously the right thing. Thanks for your thoughts.

> This package is only operational when a yank would otherwise say > (erroneously) Kill ring is empty. IMO, not claiming the kill ring is > empty after an explicit copy shouldn't really count as "smart" > :). It literally pastes there image binary as a string here. I think I would prefer the "kill ring empty" message. > What's funny is how I discovered that emacs-mac actually can paste > image data, but not backed by a file, and TIFF format only (hence a > bit useless for org mode). I simply expected it to "just work" in > org mode, blithely pasted an image in, and was very surprised to > find this feature missing. But what about the specifics tho? How do you expect org-mode to store the image? link? attachment? etc. [*] I think it all comes down to the state of mentality. Having used to interfaces that do not handle really handle images (or expected to, tbh), I do not find the current status quo surprising. > But I agree with you on the issue of ambiguous cases like HTML, > etc. A corner case the package does address is when you "Copy Image" > from a browser. In addition to the bitmap image data, the URL of the > image (or whatever it links to) is also present on the clipboard (at > least on Mac). So what would be the least surprising thing to do > there? Given that I could have opted to "Copy Image Link", I think > inserting the image data is still obviously the right thing. Indeed, there's no right choice here. You could ask the user for what they want but then it would not be seamless anymore. [*] FWIW, those are questions that I am asking myself for when I eventually incorporate yank-media into my org-mode workflow. I still haven't figured it out but I'm leaning towards org-attachments.

> It literally pastes there image binary as a string here. Yes that's also not good behavior. The hope is to do something sensible where images make sense. That might include reporting "nothing to yank here" or "images cannot be yanked here" in some modes. >But what about the specifics tho? How do you expect org-mode to store the image? link? attachment? etc. Presumably user configurable. But attachments make a considerable amount of sense for "something I want to link to and persist which is not already a file on disk"... which is why this package uses them! One small problem is attachments are "one way"; i.e. if you remove a link to an attachment, it remains forever in the attachment dir. But for the `:ID:` flavor it's quite possible to trim out unused attachments.