Hi Jack:
Do you have a patch? I’m not an org-mode user so I can’t test this myself.
Thanks
--
Rodney Sparapani, Associate Professor of Biostatistics,
He/Him/His
Vice President, Wisconsin Chapter of the American Statistical Association
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus
From:
ESS-core <ess-core-bounces@r-project.org> on behalf of Ihor Radchenko <yantar92@posteo.net>
Date: Wednesday, January 10, 2024 at 6:15 AM
To: Jack Kamm <jackkamm@gmail.com>, ESS-core@r-project.org <ESS-core@r-project.org>
Cc: Liu Hui <liuhui1610@gmail.com>, emacs-orgmode@gnu.org <emacs-orgmode@gnu.org>
Subject: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)
ATTENTION: This email originated from a sender outside of MCW. Use caution when clicking on links or opening attachments.
________________________________
Hi,
I'd like to request a new ESS feature that will allow to choose which
session is created by ESS when no session is yet associated with a
buffer.
Currently, `ess-request-a-process' unconditionally re-uses an existing
ESS process with appropriate `ess-dialect', even when such process is
not consistent with `ess-gen-proc-buffer-name-function'.
This behavior puts Org mode's ESS support in somewhat difficult position
- Org mode allows multiple sessions in Org src blocks, and we want some
way to tell ESS which session process to use for any given buffer
without actually starting that process manually.
We had a hope that setting `ess-gen-proc-buffer-name-function' would
suffice and that ESS would start a new process according to
`ess-gen-proc-buffer-name-function' when no process is yet associated
with buffer. But it is not the case.
Some more context:
(full thread is in
<https://urldefense.com/v3/__https://list.orgmode.org/CAOQTW-O*qs7xAeP7Bemu4ThM4-oGJYxxD*K2jAAw-w7RHtX2gQ@mail.gmail.com/T/*maa33e7c3f72b5c81deb91e1a1d27d57725097fa4__;Kysj!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag8V97kuVRUbqj41mRZtQD1vyJBoGvlQ$
>)
Jack Kamm <jackkamm@gmail.com> writes:
> I tested the patch (plus the additional change to org-src.el), with an
> Org file with following 2 blocks:
>
> #+begin_src R :session foo :results output
> print('foo')
> #+end_src
>
> #+begin_src R :session *bar* :results output
> print('bar')
> #+end_src
These are two R blocks that should be associated with two different ESS
R processes.
> On block "foo", I did C-', and then ess-eval-line. It creates a session
> named "foo", as expected.
When we edit the first block and when no ESS process is available,
`ess-eval-line' respects `ess-gen-proc-buffer-name-function' set by Org
mode, and creates a new ESS process "foo".
> On block "*bar*", I did the same. It does not create session named
> "*bar*", instead evaluating in session "foo". It seems ESS will always
> assume you want to evaluate in existing session if one exists, rather
> than start a new associated session, and it seems there is no way to
> tell it to behave otherwise.
But when the "foo" process is already running, despite different
`ess-gen-proc-buffer-function', `ess-eval-line' connects to the existing
"foo" process rather than "*bar*", as we anticipated.
> However, calling "M-x R" while editing block "*bar*" does create session
> "*bar*" with correct name.
>
> After sessions "foo" and "*bar*" have both been created, doing C-' and
> then ess-eval-line will evaluate in the correct session.
The only workaround, which is not ideal, is to start ESS process
unconditionally. We'd like this to change.
> 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.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://urldefense.com/v3/__https://orgmode.org/__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag8V97kuVRUbqj41mRZtQD1vxMkIQ3lQ$ >.
Support Org development at <https://urldefense.com/v3/__https://liberapay.com/org-mode__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag8V97kuVRUbqj41mRZtQD1vzCeD9KoQ$ >,
or support my work at <https://urldefense.com/v3/__https://liberapay.com/yantar92__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag8V97kuVRUbqj41mRZtQD1vykpYx2Qw$ >
_______________________________________________
ESS-core list:
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/ess-core__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag8V97kuVRUbqj41mRZtQD1vycT2vdFw$
|