Ihor Radchenko writes: > Björn Bidar writes: > >>> IMHO, it would be best to pass image file name/raw image data to >>> `org-link-preview-image-data', not an image object and call >>> `org--create-inline-image' from inside `org-link-preview-image-data'. >>> That way, we can automatically obey Org customization wrt image >>> alignment, image width, and image max width. >> >> For that case using org-link-preview-file should be sufficient? > > Sorry, I am lost. > AFAIU, your original motivation was: > > >> Would it be possible to also handle image data in the function or > >> refactor the org-link-preview-file function in a way that the geometry > >> handling is done in a helper function which can be reused by other > >> handlers. > > Did it change? It didn't but if the handler which would the uses a raw (temporary) file it could have used org-link-preview-file, which essentially meant that the handler which uses org-link-preview file is a proxy for it. The thing that confused me, but I think I wasn't aware of not getting it yesterday was that org--create-inline-image creates the actual image object. I was thinking that the image object would have been created in the handler and then passed to the helper function. I think what also confused me that org--create-inline-image talks about files not image-data. Do I understand correctly that for image-data the handling of files in line 1035 is just skipped? Another that I just came to mind what is better for such a use case the use of a buffer or a variable to store the image data? Url (and eww) for example usually uses buffers. I updated my patch with the recommended changes and updated the docstring accordingly.