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