> 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 writes:
> Ihor Radchenko 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.
>
>
