From: Ihor Radchenko <yantar92@posteo.net>
To: Jack Kamm <jackkamm@gmail.com>, ESS-core@r-project.org
Cc: Liu Hui <liuhui1610@gmail.com>, 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)
Date: Wed, 10 Jan 2024 12:18:25 +0000 [thread overview]
Message-ID: <87cyu9qt4e.fsf@localhost> (raw)
In-Reply-To: <87le8x3e0a.fsf@gmail.com>
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://list.orgmode.org/CAOQTW-O+qs7xAeP7Bemu4ThM4-oGJYxxD+K2jAAw-w7RHtX2gQ@mail.gmail.com/T/#maa33e7c3f72b5c81deb91e1a1d27d57725097fa4>)
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://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2024-01-10 12:16 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 10:18 [PATCH] Set Python shell in Org edit buffer Liu Hui
2023-12-05 11:51 ` Ihor Radchenko
2023-12-06 4:41 ` Liu Hui
2023-12-06 13:23 ` Ihor Radchenko
2023-12-07 4:45 ` Liu Hui
2023-12-07 10:36 ` Ihor Radchenko
2023-12-07 14:17 ` Liu Hui
2023-12-07 15:19 ` Ihor Radchenko
2023-12-08 10:19 ` Liu Hui
2023-12-08 13:09 ` Ihor Radchenko
2023-12-09 2:33 ` Liu Hui
2023-12-09 10:32 ` Ihor Radchenko
2023-12-09 13:36 ` Liu Hui
2023-12-27 6:04 ` Jack Kamm
2023-12-28 11:48 ` Ihor Radchenko
2023-12-31 18:31 ` Jack Kamm
2024-01-05 13:45 ` Ihor Radchenko
2024-01-05 23:29 ` Christopher M. Miles
2024-01-12 11:58 ` [ob-clojure] Clojure sessions in Org Src buffers (was: [PATCH] Set Python shell in Org edit buffer) Ihor Radchenko
2024-01-07 6:07 ` [PATCH] Set Python shell in Org edit buffer Jack Kamm
2024-01-07 12:54 ` Ihor Radchenko
2024-01-07 19:06 ` Jack Kamm
2024-01-07 23:14 ` William Denton
2024-01-08 12:26 ` Ihor Radchenko
2024-01-09 4:09 ` Jack Kamm
2024-01-09 4:25 ` Jack Kamm
2024-01-09 18:16 ` Ihor Radchenko
2024-01-10 6:21 ` Jack Kamm
2024-01-10 12:18 ` Ihor Radchenko [this message]
2024-01-10 19:14 ` [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer) Sparapani, Rodney
2024-01-10 19:15 ` Sparapani, Rodney
2024-01-10 19:31 ` Ihor Radchenko
2024-01-10 19:39 ` Sparapani, Rodney
2024-01-10 20:15 ` Ihor Radchenko
2024-01-10 21:44 ` [External] " Richard M. Heiberger
2024-01-10 21:53 ` Ihor Radchenko
2024-01-21 11:48 ` [PATCH] " Ihor Radchenko
2024-01-21 18:21 ` Sparapani, Rodney
2024-01-22 12:13 ` Ihor Radchenko
2024-01-22 13:46 ` Martin Maechler
2024-01-25 13:09 ` Ihor Radchenko
2024-01-25 15:23 ` Sparapani, Rodney
2024-01-25 15:33 ` Ihor Radchenko
2024-01-25 15:42 ` Sparapani, Rodney
2024-01-25 22:47 ` Ihor Radchenko
2024-01-10 12:19 ` [PATCH] Set Python shell in Org edit buffer Ihor Radchenko
2024-01-14 17:23 ` Jack Kamm
2024-01-16 13:49 ` Ihor Radchenko
2024-01-16 16:05 ` Jack Kamm
2024-01-28 19:12 ` Ihor Radchenko
2024-01-29 4:23 ` Jack Kamm
2023-12-27 6:07 ` Jack Kamm
2023-12-28 11:51 ` Ihor Radchenko
2023-12-29 16:04 ` Jack Kamm
2023-12-31 13:05 ` Ihor Radchenko
2023-12-31 18:14 ` Jack Kamm
2024-01-05 14:00 ` Ihor Radchenko
2023-12-29 22:20 ` Jack Kamm
2023-12-30 7:08 ` Liu Hui
2024-01-28 20:35 ` Ihor Radchenko
2024-01-29 4:21 ` Jack Kamm
2024-01-29 13:31 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cyu9qt4e.fsf@localhost \
--to=yantar92@posteo.net \
--cc=ESS-core@r-project.org \
--cc=emacs-orgmode@gnu.org \
--cc=jackkamm@gmail.com \
--cc=liuhui1610@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).