Re: [PATCH] Set Python shell in Org edit buffer

[Jack Kamm]

Ihor Radchenko <yantar92@posteo.net> writes:

>> It's annoying there's no way to tell ESS to start new session instead of
>> evaluating in existing one. Here are a few alternatives we could
>> consider to deal with this:
>>
>> 1. Change the worg/ORG-NEWS, to suggest users make sure the session
>> exists (either by evaluating a source block or call "M-x R" in edit
>> block) before running ess-eval-line.
>>
>> 2. Add ob-R and ob-julia customization options (as previously suggested)
>> to explicitly control the startup behavior (either to auto-start, or not).
>>
>> 3. Submit PR to ESS to add a variable we could let-bind, to force it to
>> start an associated session rather than evaluate in an existing
>> non-associated sessions.
>>
>> Currently I lean towards a combination of #1 and #3, but am not sure,
>> and happy to go with whatever you think is best.
>
> We can also advice `ess-request-a-process' as a temporary workaround.

My concern is that advising `ess-request-a-process' would cause
maintenance burden on ob-R. It would require some knowledge about the
ESS internals to maintain properly.

Reading through `ess-request-a-process' is rather daunting, and it
doesn't look straightforward to patch it to behave as we want. I think
the reason is because ESS allows you to call `rename-buffer' on the
inferior R session, and still have it remain associated with its editing
buffers. Which is quite a different model than the way python.el works.

After some more thought, I'm now leaning towards #2 as the best and
simplest option. In particular, I think ob-R should have an option
`org-babel-R-start-session-on-edit', which would have 2 options, nil
(default) or t. No need to add an option for the current "earmuffs"
behavior unless we find someone who actually wants it. Then, update Worg
documentation to suggest manually calling "M-x R" if session hasn't
already started yet, or to set `org-babel-R-start-session-on-edit' if
the user would like that behavior.

The alternative (trying to make `ess-eval-line' smart enough to start
new session without user intervention) seems overcomplicated from Org
development/maintenance POV, for too little gain. Clear documentation
and configuration options on Org side are good enough. This is a bit of
an edge case anyways, and unless there is interest from the ESS
developers, I think it is too much struggle to try and change how ESS
works for this. (But thank you for emailing ESS to ask).