emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] FAILED test-ob-python/session-multiline


From: Jack Kamm
Subject: Re: [BUG] FAILED test-ob-python/session-multiline
Date: Sun, 15 Oct 2023 16:56:51 -0700

Ihor Radchenko <yantar92@posteo.net> writes:

>> 1. In addition to printing `org-babel-python-eoe-indicator' after
>>    execution, we could also print out a "beginning of execution"
>>    indicator before execution, and then capture the output between the
>>    beginning and end indicators. This is how the async session
>>    execution works, and should avoid any possibility of capturing
>>    prompts.
>
> This idea looks interesting. Although I would not be so sure that it
> will fix things - I have learned that comint has many edge cases we may
> not easily anticipate.
>
> For example, see the discussion in
> https://yhetil.org/emacs-devel/87y1tgqhmc.fsf@localhost/

I think this strategy could work better in ob-python than ob-shell
because ob-python sends code to a temp file and executes the whole file
at once, which should prevent prompts arising between commands.

I will probably try this approach next, if the fix I just sent here
doesn't work out:

87h6mrihfg.fsf@gmail.com/">https://list.orgmode.org/87h6mrihfg.fsf@gmail.com/

>>    Alternatively, we could add an argument to
>>    `python-shell-send-string-no-output' to avoid suppressing output,
>>    submit it upstream to python.el, and then backport to Org to
>>    support older emacs versions.
>
> If we can (eventually) remove some custom code from Org and move it to
> Emacs, it will be the best for working towards RMS request
> https://orgmode.org/list/E1kIPh1-0001Lu-Rg@fencepost.gnu.org

I started down this path here:

https://lists.gnu.org/archive/html/emacs-devel/2023-10/msg00004.html

But I haven't followed up because I started to have some doubts. In
particular, `python-shell-send-string-no-output' will terminate once it
detects a prompt, so if some output looks like it ends in a prompt then
it will terminate prematurely. Whereas in our current indicator-based
approach, the user accidentally emitting
`org-babel-python-eoe-indicator' is unlikely.

Another approach I have considered is to redirect sys.stdout from within
Python. In particular, set it to a custom class inheriting from IOBase
during the block's execution, that both prints and saves the output. I
think this approach could ultimately be more robust, and without needing
to print an ugly indicator token, but it could be complicated to do it
right.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]