Ihor Radchenko <yanta...@posteo.net> writes:
> Bruno Barbier <brubar...@gmail.com> writes:
>
>> Note that only the first 5 patchs are real patchs. The remaining things
>> are just a demo how it could be used. The current async (ob-comint)
>> depends on writing UUIDs in org files, and, that's why I couldn't use it
>> as a demo. I'm thinking about dropping the patch:
>>
>> 'ob-core async: Add org-babel--async tools [2/5]'
>>
>> and just provide an other new keyword (feedbacks-with) so that anybody
>> may plug its own feedback process.
>
> May you please clarify if adding the new code block parameter that
> defines custom execute function is something you want to add to Org mode
> or just a helper code to demo you main patch?
Yes. (I thought about adding it in a separate request; but that would be
simpler to include it.)
>>> Or consider user running an src block, quickly editing it, and then
>>> running again. What should we do then? Should we stop the first running
>>> process?
>>
>> To keep things simple and generic, I would just forbid the user to
>> reschedule the task until the previous outcome is available.
>
> This may not be as trivial as one might think.
> Consider
>
> #+name: foo
> #+begin_src bash :async yes
> ...
> #+end_src
>
> #+results: foo
> <pending results>
>
> Another code block with the same name will write results under
> #+results: foo
> #+name: foo
> #+begin_src bash :async yes
> ...
> #+end_src
> We can currently have multiple code blocks writing to the same place.
> And async execution should not only check is the current src block is
> scheduled, but also whether we are attempting to write to a place where
> no other running block is scheduled to write.
Today, the asynchronous execution is attached to the result; the source
code itself is not locked and stays editable.
With the current implementation, trying your example, the second execution
fails with:
Error running timer: (user-error "Cannot modify an area being
updated")
So, it's already OK I guess.
I should improve the behavior (to fail before launching the second
execution). But, the current design should work in that case.
>
>>> - on failure, Org babel sometimes uses ~org-babel-eval-error-notify~. How
>>> will it interact with asynchronous evaluation? What if we have multiple
>>> simultaneously arriving error notifications?
>>
>> In the asynchronous case, I've decided to leave the overlay in place
>> in case of errors, with the error description. Clicking on that error
>> pops up the same kind of popups as in the synchronous case.
>
> Error buffer does not necessarily appear on failure. When the code leads
> to process writing to stderr, we also display error buffer. Even if the
> process exits with 0 code.
Got it. The current design adds the popup on failure; I should make it
more flexible to allow to configure a popup on success too.
> Also, your code currently creates overlays unconditionally.
> However, when we have :results silent or :results none, Org babel must
> not modify buffer.
Yes. I'll fix it (and that one was in my TODO list :-))
But if the execution fails, I guess I'll need to provide some feedbacks
anyway, but I don't know yet how (asynchronous popups are not an option,
modifying the file neither).
Thanks for your review and questions,
Bruno
>
> --
> 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>
