emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4] Inline image display as part of a new org-link-preview sy


From: Ihor Radchenko
Subject: Re: [PATCH v4] Inline image display as part of a new org-link-preview system
Date: Tue, 17 Sep 2024 18:16:13 +0000

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

>> It means that you are scheduling every single preview batch to fire at
>> the same time. I think that the timers here should run sequentially -
>> (1) fire the first batch without delay; (2) wait org-link-preview-delay
>> and fire the next batch; (3) ...
>
> Done, and tested preview run timings to be sure.

There are still edge cases.
Consider a buffer with large number of images (I just tested with my
notes.org that has 1000+ images):

1. I run preview on the whole buffer
2. M-x list-timers shows the timer, and it is ugly:
      * 10.0s - #f(compiled-function () #<bytecode 0x6278e9619bf2d9a>
                 [(#0) ((((org-link-preview-file #<overlay from 3204266
                 to 3204357 in notes.org>
                 
"/home/yantar92/.data/a3/4fcf3a-28c5-42cb-b8cc-eb98dcdb5338/stress-strain-DA1P5.png"
                 (link (:standard... [the line spans thousands of
                 characters further - rendering timer list takes a good
                 10+ sec]
   - So, no closures please. Use normal named functions
   - It may also be a good idea to manage preview queue globally, so
     that subsequent preview requests can be merged automatically (see
     below)
3. It will take a long time to preview all those images, so I get
   impatient and cancel the previews. The timer still remains...
4. I request previews in the whole buffer again. Now, there are two
   timers. This may be repeated, and the user may end up with many
   useless idle timers - each of them will take a long time to end,
   because "preview batches" do not care whether we actually try to
   preview images or skip them because the underlying overlays were
   "canceled" by another command - I think that the timers should not
   group images in batches beforehand, but simply consume images from a
   single queue until a given number of images are actually submitted
   for preview generation (overlays are still present).

And please fix the compiler warnings.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]