Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/build/org/)])

[Ihor Radchenko <yantar92@posteo.net>]

Bruno Barbier <brubar.cs@gmail.com> writes:

>> 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.)

I have doubts about how useful such parameter would be for _users_. It
is certainly useful for developers of new babel backends, but I do not
see how users will use it.

I'd prefer to discuss this in a separate thread.

>> 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.

By popup, do you mean an overlay where clicking on it will raise the
usual `org-babel-eval-error-notify' buffer?
If yes, what happens if a user executes a code block, it fails, and the
user executes it again without looking at the error? (Second execution
may be triggered from a different place, indirectly, via noweb ref or
similar).

> 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).

We need something more than just an overlay. Maybe some kind of babel
execute history (in tabulated-list-mode buffer), keeping information
about execution stats and stderr data.

We may provide a mode-line or fringe indicator that will warn user if
something went wrong with recent executions. Something akin compile-mode
mode line indicator listing errors and warnings during compilation.

(Handling asynchronous messages is actually a complex topic. It has been
previously discussed on emacs-devel as well. See
<https://yhetil.org/emacs-devel/838t59j821.fsf@gnu.org/>)

-- 
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>