From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id GBPJC6qKnmXxYwEAkFu2QA (envelope-from ) for ; Wed, 10 Jan 2024 13:16:42 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 0InkB6qKnmUyJAEAqHPOHw (envelope-from ) for ; Wed, 10 Jan 2024 13:16:42 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=jruNe+PV; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1704889002; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=UBaxpK6bOl6BGQ+PrrL1Vm8lzDi9qA+PUlP9CdVgV70=; b=Pmn64Lgv/XQ9FbhKfFZ4Jlz8QVmkfgGD2mepHbo0epJgBQW14yExdyuqhUruF/+p6XrWh8 +o8TUXD71GS/S/Jpci1Xjtsn4Mn1hVf5j/7XuHsxD9oj9RLNMFRbE8AcC3mbNYFVHhuEhs 5Ks0Uznbt/rQRkA256W88apqvhqVtqpoSQEjlB4gIZIdlBOTDq6t4tNArys7AZLjA5lI1R noI10SIhZ9ouGPbKBrdN2aZrPd0pchr7XMj7L+hDcp+qtBxTdkh7W3Pf/ynVRfF2OHpNyb PW9BCpg0c0VkLmhCyW93fAoBcltutUwXbi7rOiqGE2j6zLEk5ihQ0GasJ4KtCA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1704889002; a=rsa-sha256; cv=none; b=gE3txo3KUKAA9s8kedNFvpKcQjYotSwFh2NHQs1UM9GEINbPPxEgOmys0Grc72JfiTCaaP /9cfBQykE0s3OiSTRsCdQqmIx2YX33kdGhixJS/oLbMB1vFNLgoAXRUoZr3dSi4uEFo3lX Sf4ZggaVYfRJlh34J3+vRC8BT/Q8/Aaw0m71WyRuWJX31LfnoHdobSqxZZ+yV9cheTUAcI qxLA3U9r90s1M0+7n1Xg10XpUrgJUmzlecBOQzwzVxnh3nz9emnUMOR5en9KO/zRmDAMZU eDuVsJL2aXZ8wov8FcwAEXr999043RGOTn5H8bSA6iFVVCKBrWhIe6+fGigULg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=jruNe+PV; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B633335AD9 for ; Wed, 10 Jan 2024 13:16:41 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNXUb-0007eJ-Gg; Wed, 10 Jan 2024 07:15:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNXUW-0007dS-0X for emacs-orgmode@gnu.org; Wed, 10 Jan 2024 07:15:29 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNXUR-0002V7-VI for emacs-orgmode@gnu.org; Wed, 10 Jan 2024 07:15:27 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3BB90240029 for ; Wed, 10 Jan 2024 13:15:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1704888919; bh=3cynBKpLmhFfjunPVkAs7HF/h8382S5Uds4t/rTNtAc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=jruNe+PV4m8nH589/nIyh9I81k7ZoJTY/n4NFhbk+ccwn5DSA1qDgqoyGQB4RJTnE L10p48dsAOYtAQXWZoiJS5r64eHBe2afmclddBdoJuk5gWKd6wifF3A3RDIpG6tMM+ IdP8I0Vc46lOm9/T9yugoFN9EU/3Un4kAVa+dqkorrJBNTl0fqJrs8V8a8Dw6XeFQd SsVhcYt4uxbrR+jBgdRtYO+JCyIZVDAiEi9NlbZhZBavU9kxkxW3+LrC2ypsgQ9Mlf qC02hcd2OgwRaJfsHMcCBOEEye+BU4W0x5tevoCt42sJ6a0rHlVvhupphzaa2UHhds OTqe8QMxjxXDQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4T96FK6KCYz9rxG; Wed, 10 Jan 2024 13:15:17 +0100 (CET) From: Ihor Radchenko To: Jack Kamm , ESS-core@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) In-Reply-To: <87le8x3e0a.fsf@gmail.com> References: <878r6647vv.fsf@localhost> <87bkb2rqer.fsf@localhost> <87edfwsuvx.fsf@localhost> <87sf4bsm1w.fsf@localhost> <87mstw18r4.fsf@gmail.com> <87bkaak0ol.fsf@localhost> <87ttnyz0jv.fsf@gmail.com> <87wmsn6ghw.fsf@localhost> <87o7dxu15h.fsf@gmail.com> <87msthwbfz.fsf@localhost> <87le91t13e.fsf@gmail.com> <87zfxgxb8m.fsf@localhost> <87r0ir2ln8.fsf@gmail.com> <87zfxewewe.fsf@localhost> <87le8x3e0a.fsf@gmail.com> Date: Wed, 10 Jan 2024 12:18:25 +0000 Message-ID: <87cyu9qt4e.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.51 X-Spam-Score: -9.51 X-Migadu-Queue-Id: B633335AD9 X-Migadu-Scanner: mx12.migadu.com X-TUID: lyKDWiVFMa5q 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