> That's a very elegant way to add the threading! Thanks for kind words.
> The performance penalty > is noticeable, but the tradeoff could be worth it in some cases, like a > background agenda refresh on a timer, or after a "remote" edit. I can > imagine an org-agenda-refresh-async command that would add that advice > and remove them in an unwind-protect. That may be a good way to go. Probably, even refreshing agenda in a separate copy of agenda buffer, so that the current version remains usable. > The first thing that comes to mind is to set buffer-read-only on each > buffer before it is scanned, and unset it when done with a buffer. That > might not be doable with advice. This is not enough. If you accidentally move the point in the buffer being processed by agenda, the results may be unpredictable (org-agenda-get-* functions move across the buffer with re-search-forward). Any ideas how to deal with this? Best, Ihor Adam Porter <a...@alphapapa.net> writes: > Ihor Radchenko <yanta...@gmail.com> writes: > >>>> Asynchronous code is not faster; it's generally slower because of >>>> yielding and synchronization. >> >>> Anyway, I will try to throw yields into agenda code just to check how >>> bad the performance can degrade. >> >> With the following code, org-agenda-redo runs for 21 second on my >> system, while without threads it is 16 seconds. However, emacs remains >> responsive during rebuilding agenda! >> >> (define-advice org-agenda-redo (:around (oldfun &optional all) make-async) >> (make-thread (lambda () (funcall oldfun all)) "org-agenda-redo")) >> (define-advice org-agenda-skip-eval (:around (oldfun form) make-async) >> (thread-join (make-thread (lambda () (funcall oldfun form)) >> "org-agenda-skip-eval"))) > > That's a very elegant way to add the threading! The performance penalty > is noticeable, but the tradeoff could be worth it in some cases, like a > background agenda refresh on a timer, or after a "remote" edit. I can > imagine an org-agenda-refresh-async command that would add that advice > and remove them in an unwind-protect. > >> The problem, of course, is that touching agenda buffer and org buffers >> may be risky while org-agenda-redo is running. >> Wondering if it is possible to block user commands during that time. > > The first thing that comes to mind is to set buffer-read-only on each > buffer before it is scanned, and unset it when done with a buffer. That > might not be doable with advice. > >
