[PATCH] Persistently save downloaded inline remote images

[PATCH] Persistently save downloaded inline remote images

[Ferdinand Pieper]

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

Currently remote images are downloaded upon each display.
As most of the time the images do not change in between redisplays, we can instead buffer the images locally and only update the local copy when the remote image is updated.

Attached is a proposed patch.


Best,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-Persistently-save-downloaded-inline-remote-im.patch --]
[-- Type: text/x-diff, Size: 1663 bytes --]

From aa34ad1176f4599c5a3c2678806644f16a3d22a2 Mon Sep 17 00:00:00 2001
From: fpi <git@pie.tf>
Date: Tue, 23 Jun 2020 15:59:28 +0200
Subject: [PATCH] org.el: Persistently save downloaded inline remote images

* lisp/org.el (org--create-inline-image): Save downloaded inline
remote images to temporary directory to persist them for future
`org-display-inline-images' calls.
---
 lisp/org.el | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 4d46b4173..7b649d6d0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16277,10 +16277,22 @@ according to the value of `org-display-remote-inline-images'."
 	 (file-or-data
 	  (pcase org-display-remote-inline-images
 	    ((guard (not remote?)) file)
-	    (`download (with-temp-buffer
-			 (set-buffer-multibyte nil)
-			 (insert-file-contents-literally file)
-			 (buffer-string)))
+	    (`download (let ((new (concat temporary-file-directory
+					  "tramp/"
+					  (file-remote-p file 'host)
+					  (file-local-name file))))
+			 ;; dont download file if local copy exists & is newer than remote
+			 (if (and (file-exists-p new)
+				  (file-newer-than-file-p new file))
+			     (with-temp-buffer
+			       (set-buffer-multibyte nil)
+			       (insert-file-contents-literally new)
+			       (buffer-string))
+			   (with-temp-file new
+			     (make-directory (file-name-directory new) t)
+			     (set-buffer-multibyte nil)
+			     (insert-file-contents-literally file)
+			     (buffer-string)))))
 	    (`cache (let ((revert-without-query '(".")))
 		      (with-current-buffer (find-file-noselect file)
 			(buffer-string))))
-- 
2.20.1

Re: [PATCH] Persistently save downloaded inline remote images

[Kyle Meyer]

Thanks for the patch, and sorry about the slow response.

Ferdinand Pieper writes:

> Currently remote images are downloaded upon each display.  As most of
> the time the images do not change in between redisplays, we can
> instead buffer the images locally and only update the local copy when
> the remote image is updated.

Hmm, I'm guessing this was left as a simple download given that there is
also a `cache' option that keeps the image around in a separate buffer.
Does that value help for your use case?

Jack, as the author of the org-display-remote-inline-images commit, what
do you think about this patch?

Re: [PATCH] Persistently save downloaded inline remote images

[Jack Kamm]

> Jack, as the author of the org-display-remote-inline-images commit, what
> do you think about this patch?

This patch takes the same approach as an earlier attempt by Kit in 2014
[1].  That patch was never merged; Michael objected that the approach
seemed too complex, and suggested using file-local-copy and cacheing the
filename instead; he also suggested implementing this cacheing
functionality in Tramp instead of Org.

So, when I submitted a new attempt at this, I chose to cache by simply
opening the image files in Emacs instead, since the implementation is
much simpler, and would hopefully sidestep the objections from the 2014
approach.

While cacheing via tempfiles is more complex, it does have some
benefits: it allows cacheing across Emacs sessions, and it avoids the
side effect of opening the image files in Emacs.

I'm agnostic whether tempfiles or Emacs buffers are ultimately
better. My inclination is to be conservative and stick with the status
quo unless there's a compelling reason to switch.

So, I suggest Ferdinand confirm he's tested the existing "cache" option,
and articulate why he found it unsuitable, before merging this.

If we do proceed in this direction, I'd suggest replacing the current
cache mechanism entirely -- I don't see a good reason to maintain 2
solutions to the same problem. Also, we could combine the "download" and
"cache" options into a single implementation, making them synonyms for
backwards compatibility.

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00690.html
[2] https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00177.html

Re: [PATCH] Persistently save downloaded inline remote images

[Bastien]

Hi,

Jack Kamm <jackkamm@gmail.com> writes:

> So, I suggest Ferdinand confirm he's tested the existing "cache" option,
> and articulate why he found it unsuitable, before merging this.

As no feedback was received, I'm discarding this patch.

Re: [PATCH] Persistently save downloaded inline remote images

[Bastien]

Hi Jack,

Jack Kamm <jackkamm@gmail.com> writes:

> If we do proceed in this direction, I'd suggest replacing the current
> cache mechanism entirely -- I don't see a good reason to maintain 2
> solutions to the same problem. Also, we could combine the "download" and
> "cache" options into a single implementation, making them synonyms for
> backwards compatibility.

I just added a call for help about this.  Thanks!

Re: [PATCH] Persistently save downloaded inline remote images

[Jack Kamm]

Canceled.

> I just added a call for help about this.  Thanks!

This help request is old, and also it was never clear what concrete
enhancement was desirable, or what specific problem there was with the
existing cacheing mechanism. So I think it just adds noise to
updates.orgmode.org.

Therefore, I am canceling the help request (or rather, attempting to
cancel it with Woof -- this is my first time using Woof like this, so
apologies in advance if it doesn't work).

Re: [PATCH] Persistently save downloaded inline remote images

[Ihor Radchenko]

Jack Kamm <jackkamm@gmail.com> writes:

> Therefore, I am canceling the help request (or rather, attempting to
> cancel it with Woof -- this is my first time using Woof like this, so
> apologies in advance if it doesn't work).

Thanks for taking care of this!

> This help request is old, and also it was never clear what concrete
> enhancement was desirable, or what specific problem there was with the
> existing cacheing mechanism. So I think it just adds noise to
> updates.orgmode.org.

As an update from the time this patch has been submitted, we now have
org-persist library that allow caching downloaded files, as one of the
possibilities. Such caching is already being used during export. See
6ee45518f.

Best,
Ihor