Re: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Sparapani, Rodney]

I see.  But, I assume that you meant…
8. Observe that the line still goes to "session1"

I usually launch another emacs for “session2”.
There’s probably a way to do this manually,
but, I take your point.  However, if you are a
non-user, then why do you care?

--
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: Ihor Radchenko 
Date: Wednesday, January 10, 2024 at 1:28 PM
To: Sparapani, Rodney 
Cc: Jack Kamm , ess-c...@r-project.org 
, Liu Hui , emacs-orgmode@gnu.org 

Subject: Re: [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.


"Sparapani, Rodney"  writes:

> Hi Ihor:
>
> Do you have a patch?  I’m not an org-mode user so I can’t test this myself.
> Thanks

Well. I am not exactly ESS user, so I wanted to get a general feedback
first before trying anything blindly.

I think I can demonstrate the problem we are facing without forcing you
to use Org mode though:

1. create and open test.R file containing
   x = "foo"
2. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session1"))
3. M-x ess-eval-line
4. Observe "session1" R comint buffer displayed
5. create and open test2.R file containing
   y = "bar"
6. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session2"))
7. M-x ess-eval-line
8. Observe that the line still goes to "session2"

As a non-user, I am not sure if the above is a bug or just some kind of
missing feature. However, for comparison, python.el allows setting
`python-shell-buffer-name' and doing steps similar to the above will
yield two independent python shells to interact with.

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at 
<https://urldefense.com/v3/__https://orgmode.org/__;!!H8mHWRdzp34!-wEqGdchA5j_KbsspJFtmyWNRaCHt2I9O995IbqLTDFlr_k-WFr8eKVdxmlYby3I--FsLJJplSjQzj5f4w$
 >.
Support Org development at 
<https://urldefense.com/v3/__https://liberapay.com/org-mode__;!!H8mHWRdzp34!-wEqGdchA5j_KbsspJFtmyWNRaCHt2I9O995IbqLTDFlr_k-WFr8eKVdxmlYby3I--FsLJJplSi71O7Wsw$
 >,
or support my work at 
<https://urldefense.com/v3/__https://liberapay.com/yantar92__;!!H8mHWRdzp34!-wEqGdchA5j_KbsspJFtmyWNRaCHt2I9O995IbqLTDFlr_k-WFr8eKVdxmlYby3I--FsLJJplSjYCog7Mw$
 >

Re: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Sparapani, Rodney]

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  on behalf of Ihor Radchenko 

Date: Wednesday, January 10, 2024 at 6:15 AM
To: Jack Kamm , ess-c...@r-project.org 

Cc: Liu Hui , 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
)

Jack Kamm  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 
.
Support Org development at 
,
or support my work at 


___
ESS-core list: 

Re: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Sparapani, Rodney]

Oops!  Sorry, I misread the signature.  That should be…

Hi Ihor:

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: Sparapani, Rodney 
Date: Wednesday, January 10, 2024 at 1:14 PM
To: Ihor Radchenko , Jack Kamm , 
ess-c...@r-project.org 
Cc: Liu Hui , emacs-orgmode@gnu.org 

Subject: Re: [FR] Add buffer-local setting to request specific ESS 
process/session name (was: [PATCH] Set Python shell in Org edit buffer)
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  on behalf of Ihor Radchenko 

Date: Wednesday, January 10, 2024 at 6:15 AM
To: Jack Kamm , ess-c...@r-project.org 

Cc: Liu Hui , 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-w7rhtx...@mail.gmail.com/T/*maa33e7c3f72b5c81deb91e1a1d27d57725097fa4__;Kysj!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag8V97kuVRUbqj41mRZtQD1vyJBoGvlQ$
 >)

Jack Kamm  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 v

Re: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Ihor Radchenko]

"Sparapani, Rodney"  writes:

> I see.  But, I assume that you meant…
> 8. Observe that the line still goes to "session1"

Yup.

> I usually launch another emacs for “session2”.
> There’s probably a way to do this manually,
> but, I take your point.  However, if you are a
> non-user, then why do you care?

Org mode supports multiple ESS sessions in Org mode src blocks
(https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html#org2a21acd)

However, we currently have to use a workaround that does not always work
well to assign separate sessions to R source blocks in Org mode.
ESS is the only comint mode that requires such workaround and does not
allow setting a specific process buffer name for a given R buffer.

We recently discovered `ess-gen-proc-buffer-name-function', but it does
not work as we expected, unfortunately. (which is either because we
misunderstand something or because there is a bug).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Ihor Radchenko]

"Sparapani, Rodney"  writes:

> Hi Ihor:
>
> Do you have a patch?  I’m not an org-mode user so I can’t test this myself.
> Thanks

Well. I am not exactly ESS user, so I wanted to get a general feedback
first before trying anything blindly.

I think I can demonstrate the problem we are facing without forcing you
to use Org mode though:

1. create and open test.R file containing
   x = "foo"
2. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session1"))
3. M-x ess-eval-line
4. Observe "session1" R comint buffer displayed
5. create and open test2.R file containing
   y = "bar"
6. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session2"))
7. M-x ess-eval-line
8. Observe that the line still goes to "session2"

As a non-user, I am not sure if the above is a bug or just some kind of
missing feature. However, for comparison, python.el allows setting
`python-shell-buffer-name' and doing steps similar to the above will
yield two independent python shells to interact with.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at