> 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.
Only LaTeX previews for now. As you may be aware, the patchset also includes asynchronous pdf exports (using org-async), which makes a huge difference in Org's usability when iterating on a document and running frequent exports. >>> 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 :) Unfortunately I don't think I'm good at designing flexible async APIs, at least in Emacs. (The LaTeX preview system is being tuned for speed/lag-free performance, not flexibility.) I think documenting that a failed async preview should call org-link-preview-clear on the link is good enough for now. Karthik
