Jack Kamm 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 wh
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
Hi Jack,
Jack Kamm 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, maki
Hi,
Jack Kamm 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.
> 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-loc
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
> t
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,
>From aa34ad1176f4599c5a3
