emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Björn Bidar" <bjorn.bidar@thaodan.de>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Karthik Chikmagalur <karthikchikmagalur@gmail.com>,
	emacs-orgmode@gnu.org
Subject: Re: Link preview generation with new link preview property
Date: Tue, 21 Jan 2025 22:45:16 +0200	[thread overview]
Message-ID: <877c6nuc9v.fsf@> (raw)
In-Reply-To: <87cyggq8eg.fsf@localhost> (Ihor Radchenko's message of "Tue, 21 Jan 2025 19:22:31 +0000")

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

Ihor Radchenko <yantar92@posteo.net> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> 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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-link-Split-link-preview-into-two-functions.patch --]
[-- Type: text/x-patch, Size: 3568 bytes --]

From 51d94bf20b043be635af3719464dccd0cc589f93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Bidar?= <bjorn.bidar@thaodan.de>
Date: Fri, 20 Dec 2024 01:00:46 +0200
Subject: [PATCH] org-link: Split link preview into two functions

* lisp/ol.el (org-link-preview-file,
org-link-preview-image-data): Split up the actual preview part into
a separate function.  The new preview function can be called by
:preview handler to display the raw image according to the correct
alignment and with for the link to be previewed. Passing the link can
be skipped if alignment and with are given.
---
 lisp/ol.el | 44 ++++++++++++++++++++++++++++++--------------
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index 43fac7433..0429e257c 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -2178,23 +2178,39 @@ (defun org-link-preview-file (ov path link)
 
 This is intended to be used as the `:preview' link property of
 file links, see `org-link-parameters'."
-  (when (display-graphic-p)
-    (require 'image)
     (when-let* ((file-full (expand-file-name path))
                 (file (substitute-in-file-name file-full))
                 ((string-match-p (image-file-name-regexp) file))
                 ((file-exists-p file)))
-      (let* ((width (org-display-inline-image--width link))
-	     (align (org-image--align link))
-             (image (org--create-inline-image file width)))
-        (when image            ; Add image to overlay
-	  ;; See bug#59902.  We cannot rely
+	  (org-link-preview-image-data ov file link)))
+
+(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 ALIGN and/or WIDTH are not given, they are derived from LINK object
+\(ast node\).
+If LINK is nil, ALIGN and WIDTH have to be given.
+
+An image object is created from IMAGE-DATA to be displayed in overlay.
+
+This intended to be used by functions which provide the :preview link property
+of links such as in `org-link-preview-file'"
+  (if (or (and align width)
+          link)
+      (when (display-graphic-p)
+        (require 'image)
+        (when-let* ((align (or align
+                               (org-image--align link)))
+                    (width (or width
+                               (org-display-inline-image--width link)))
+                    (image-object (org--create-inline-image image-data width)))
+          ;; See bug#59902.  We cannot rely
           ;; on Emacs to update image if the file
           ;; has changed.
-          (image-flush image)
-	  (overlay-put ov 'display image)
-	  (overlay-put ov 'face 'default)
-	  (overlay-put ov 'keymap image-map)
+          (image-flush image-object)
+          (overlay-put ov 'display image-object)
+          (overlay-put ov 'face 'default)
+          (overlay-put ov 'keymap image-map)
           (when align
             (overlay-put
              ov 'before-string
@@ -2202,9 +2218,9 @@ (defun org-link-preview-file (ov path link)
               " " 'face 'default
               'display
               (pcase align
-                ("center" `(space :align-to (- center (0.5 . ,image))))
-                ("right"  `(space :align-to (- right ,image)))))))
-          t)))))
+                ("center" `(space :align-to (- center (0.5 . ,image-data))))
+                ("right"  `(space :align-to (- right ,image-data))))))))
+        (error "Either align and width or link have to be passed"))))
 
 ;;;; "help" link type
 (defun org-link--open-help (path _)
-- 
2.45.2


  reply	other threads:[~2025-01-21 20:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6755f138.0c0a0220.40388.51fbSMTPIN_ADDED_BROKEN@mx.google.com>
2024-12-13  5:49 ` Link preview generation with new link preview property Karthik Chikmagalur
2024-12-14  0:03   ` Björn Bidar
2024-12-14  7:04     ` Ihor Radchenko
2024-12-17  2:46       ` Björn Bidar
2024-12-17 17:39         ` Ihor Radchenko
2024-12-19 21:55           ` Björn Bidar
2024-12-21 12:03             ` Ihor Radchenko
2024-12-17  3:42       ` Karthik Chikmagalur
2024-12-17 17:40         ` Ihor Radchenko
2024-12-19 23:20           ` Björn Bidar
2024-12-20  0:45           ` Karthik Chikmagalur
2024-12-21 12:05             ` Ihor Radchenko
2024-12-23 20:41               ` Björn Bidar
     [not found]           ` <6764aa79.050a0220.23273b.09a5SMTPIN_ADDED_BROKEN@mx.google.com>
2024-12-26 18:46             ` Karthik Chikmagalur
2024-12-29 15:44               ` Björn Bidar
2024-12-30 17:05                 ` Ihor Radchenko
2025-01-04  2:01                   ` Björn Bidar
2025-01-04 14:11                     ` Ihor Radchenko
2025-01-18 14:44                       ` Björn Bidar
2025-01-18 15:03                         ` Ihor Radchenko
2025-01-19 15:08                           ` Björn Bidar
2025-01-21 19:22                             ` Ihor Radchenko
2025-01-21 20:45                               ` Björn Bidar [this message]
2024-12-18  6:21         ` stardiviner
2024-12-18  6:33           ` Karthik Chikmagalur
2024-12-19 23:26             ` Björn Bidar
2024-12-21 12:09               ` Ihor Radchenko
2024-12-08 19:18 Björn Bidar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877c6nuc9v.fsf@ \
    --to=bjorn.bidar@thaodan.de \
    --cc=emacs-orgmode@gnu.org \
    --cc=karthikchikmagalur@gmail.com \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.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).