Re: Asynchronous org-agenda-redo

[Ihor Radchenko]

> 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 <address@hidden> writes:

> Ihor Radchenko <address@hidden> 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.
>
>