Karthik Chikmagalur <karthikchikmaga...@gmail.com> writes: >>> Do you mean something like this? >>> >>> (while (re-search-forward org-link-any-re end t) >>> ;; Make overlay ov here >>> ;; Find path, link and preview-func here >>> >>> (push (list ov preview-func path link) previews-remaining)) >>> >>> (dolist (preview-data-chunk (seq-partition previews-remaining 6)) >>> (run-with-idle-timer >>> ... >>> Where the chunk size (6) and the idle time (0.10 seconds) will be >>> customizable. >> >> Yes. > > Okay. There's one more issue to resolve. An asynchronous preview will > return t but no preview is placed yet. If the preview then fails when > the callback runs, we will have an overlay without a preview that hasn't > been cleaned up. How do you suggest handling this case? > > The only thing I can think of is that the async preview-func should call > org-link-preview-clear on the failed preview by itself, and we should > include this expectation in the org-link-parameters documentation.
Hmm... Not sure. I feel that we are going too far. Maybe we should use org-pending <https://list.orgmode.org/65df0895.df0a0220.a68c8.0...@mx.google.com/> after it is finalized. For now, my idea is to generalize the asynchronous handling - instead of doing it within individual preview functions, assume that preview functions are synchronous, but run them in chunks. If a preview function is not synchronous, it should take care about managing the passed overlay by itself. -- 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>
