Karthik Chikmagalur <karthikchikmaga...@gmail.com> writes: >> 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. > > Interesting, I didn't know about org-pending. At first I thought this > would overlap with the org-async, the process executor used for LaTeX > previews, but it looks like this is for locking buffer regions and > orthogonal to the source of the async changes. > > This is an aside, but do you think it makes sense to merge org-async > before LaTeX previews (i.e. now), so that we can get feedback on its > design?
The best test for the design is actually using it for things. If you have some feature you want to use org-async for, we can merge that feature + org-async. >> 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. > > Yes, this is what I suggested. Even chunking and running the > preview-funcs on an idle-timer seems like overengineering to me, but I > defer to your experience here. I'll update the patch soon. Implementing async is not mandatory. Here, I am simply taking into account _your_ experience with LaTeX previews. And I do know that image previews may also take time when there are many images in the buffer. So, I thought that you are probably the best person to design such things :) -- 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>
