Ihor Radchenko writes: > Björn Bidar writes: > >> 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. > > Feel free to improve the docstring. > I do agree that it may be confusing. create-image uses the term file-or-data instead of file would that be better? >> 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? > > May you please elaborate? I do not quite get your question (or maybe > have something else on that line number). I'm talking about the pcase, if the image is data the pcase largely doesn't apply. >> 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 do not think that there is much difference. Unless we have a huge number of images (in which case we may create performance problems by > increasing the number of buffers - some Emacs operations scale with the > number of buffers). > ok >> +(defun org-link-preview-image-data (ov image-data &optional link align width) >> + "Display raw image data IMAGE-DATA in overlay OV for LINK. >> + >> +If not given ALIGN and WIDTH is derived from LINK. > > If ALIGN and/or WIDTH are not given, they are derived from LINK object > (ast node). > >> +If LINK was not passed ALIGN and WIDTH have to be given. > > If LINK is nil, ... > I fixed the docstrings and move the require image to the helper function. > Also, we need to explain the possible values of ALIGN and WIDTH. > Maybe even provide some defaults (maybe even via cl-defun) Would it make sense to provide defaults for ALIGN and WIDTH when they have to be supplied or be derived from link?