From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:700:3204::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id qCRlHilCoWVVyQAAkFu2QA (envelope-from ) for ; Fri, 12 Jan 2024 14:44:09 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 6ObQGSlCoWWzUQEAe85BDQ (envelope-from ) for ; Fri, 12 Jan 2024 14:44:09 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=mcw.edu header.s=11132019PPKEY header.b=h76U5X5Z; 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=quarantine) header.from=mcw.edu; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1705067049; 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=SlSxUfSEnqumlqJ+DvvBTPTeDCnan7hD2iAi9jCcuwM=; b=BS9+f5liY9crRKp0isb7PA+iTCtlBYy4PACZ1MhP3GdUoaVA0QUtQhafPHtXqlIrow78s/ fiJGk1m6ilnLtFee4uU65w4+qRj+mqcySJoB+r3ReqtjKXIDjaoJR+ORXv1IqS9weE0qal QbLqfQBrfroidIlapey/B9ZpBr+Tm/6ZI0Tvrl55dmYspMJO6RkvR3I2PZT8d+gHTTerQE fJ/m7gzzjNSrReN+nZw3wyrasv51rJMr+PesIKXSO4swjahtPeTrZIOSS7adW3OAAdFzI3 7+3JNQpzTL8INFiYd5XcynZgMtbNEIKDMkLLS7PTBnwiYtdR+wRxIJBNEgAz1Q== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=mcw.edu header.s=11132019PPKEY header.b=h76U5X5Z; 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=quarantine) header.from=mcw.edu; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=key1; d=yhetil.org; t=1705067049; a=rsa-sha256; cv=pass; b=iaht4+oaQivPDhmLIxh4A/mKyUABT9XDCduGXEpnyx36c5ulczvgs5utiLvVkMAJOvlcNA TK+C39LKoxjYId2Xa6jn1z23W7NlU3H4lgIqf36CwtJUc3xN8tdNu3IJiN8kQl6bVWbweP ERdyOCWtIlP4DxJ9Dsn8pAkp8Rtv9y8O86aTaQuURpJHMfYEFJfC7FovXIPdmZLs4MIAr4 MY4EkQmvL9hF+Qkc6rmLo+sBee+TXGAYlklh1EZ70ZVbQicWmAswYWdjtBoXnCwWPT9ICT 0llqCkE/xWz4M9DYulVR/Sp4fzukfVhPA+d7RRZPBmm9+wg6h4hKpra1UHVFqg== 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 20B5275CEC for ; Fri, 12 Jan 2024 14:44:09 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rOHnc-0003U3-Ks; Fri, 12 Jan 2024 08:42:16 -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 1rNe2L-0003mN-O7 for emacs-orgmode@gnu.org; Wed, 10 Jan 2024 14:14:51 -0500 Received: from mx0a-0021c101.pphosted.com ([205.220.162.138]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNe2G-0007jr-Nd for emacs-orgmode@gnu.org; Wed, 10 Jan 2024 14:14:47 -0500 Received: from pps.filterd (m0195926.ppops.net [127.0.0.1]) by mx0a-0021c101.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 40AIvgCQ004995; Wed, 10 Jan 2024 13:14:39 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcw.edu; h=from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; s=11132019PPKEY; bh=SlSxUfSEnqumlqJ+ DvvBTPTeDCnan7hD2iAi9jCcuwM=; b=h76U5X5ZEynK2Svu0rfvkVRZpluUFbt0 HJ+hcYgP0F5w5w/W3+0cYeG2KiKJtOR+Ee+aSZHCVKTgCYhfBxHS8/aO3s7cBWwA QECb4/C2t5ApKCvP7udINqnjnEJ6zvHpQ+PjyeKnrrDPLDWLFhHNmndSvEYd3OAd WKJ1Qx1c5DDHhluJuq6ABZoi/fM6WsZjsyB5y2udlUZHQZu9mGgADUpwVL660p1w h3GO5zLv0ZFUljPsh+UMrMazMTei/Pqn9j+2N/W7084X6A3CXPDqyFv0ODaesp3I Bk6Pvv89mJ4cKypnFgMTki1efIvr/pVg599+CJl0qO/yXxAN37hVGA== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2168.outbound.protection.outlook.com [104.47.57.168]) by mx0a-0021c101.pphosted.com (PPS) with ESMTPS id 3vj0ys02qq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jan 2024 13:14:39 -0600 (CST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XUWp1xppNa6O7roGFIX4Ei67LU0eFtmlsxOEooxy+5KMs6+bG+FN9WlgfJKigN7WPOE8gQF8WDs8KOebr0Ehei9UQaMd09YklRP7zmaRnoofaDgXiXHcwwX4ATf4b41cZHE73uT+qPsVZ6/gRMY+/i1DiDwxnmTOjIWSaJ4ieMBYXVJJi0a9AO/ZBYPYub9r0bv54PWXOxGTFiYq5ZZzmT9kzyH4FGrNL3LvTw6pKe/DrumQQl/n19b1ddv32ic6lBsaoxp+VH0j26K8vFiAqmUAMNszRO8JYP5hCqCMO7tmd2LoiOtXsHbmNPEpx6CiqFKkChYYGYWFRtp9pwc78w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SlSxUfSEnqumlqJ+DvvBTPTeDCnan7hD2iAi9jCcuwM=; b=mL3wQr32I979CJKigecmzpAjCaQMlyEZ6iz2AKbHG3vSzZNIHA5LzmSzfm5C+Pub+uvxQnJMJifiT6S4JsB0n95PmfBo8LQtlZMabRlzS6RZqQxn2dn3tX9MI6Zg+ZNA6SwJBAc+A+IdIr8vEI3Z2NnzVfEBDFHqCBjJsVd280v2SqXDdTVFnn3dq9itOeYCbLu/ddVjmupTobQKL+ABwaDBdY43JXu0RPEm56LGhwgWB9UmOgvUT4Ko6InAojA9Ny5QXa5KrL1KLcqrjsvGwN4Dr3cqFahVkITIqousdjw+kM2h6Vil7df+zMc4qIfd9wI9nuoyUiviUsLJ09XGiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mcw.edu; dmarc=pass action=none header.from=mcw.edu; dkim=pass header.d=mcw.edu; arc=none Received: from CO6PR01MB7452.prod.exchangelabs.com (2603:10b6:303:143::7) by DM8PR01MB6823.prod.exchangelabs.com (2603:10b6:8:22::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.17; Wed, 10 Jan 2024 19:14:35 +0000 Received: from CO6PR01MB7452.prod.exchangelabs.com ([fe80::5e7a:8bb2:b564:78df]) by CO6PR01MB7452.prod.exchangelabs.com ([fe80::5e7a:8bb2:b564:78df%4]) with mapi id 15.20.7181.018; Wed, 10 Jan 2024 19:14:35 +0000 From: "Sparapani, Rodney" To: Ihor Radchenko , Jack Kamm , "ESS-core@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) Thread-Topic: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer) Thread-Index: AQHaQ762Imd3A7QGEEi/iEeozuE1PrDTarva Date: Wed, 10 Jan 2024 19:14:35 +0000 Message-ID: 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> <87cyu9qt4e.fsf@localhost> In-Reply-To: <87cyu9qt4e.fsf@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CO6PR01MB7452:EE_|DM8PR01MB6823:EE_ x-ms-office365-filtering-correlation-id: de62b6c6-6c40-43df-373a-08dc12106241 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eKcEvKbw6tdRRCNUXhmRmczavUMffFn+1cDG9E9iVP2nwMCJJNOAjN8DMw2WYhfffFQCsC+BXRXAcfdKVypL3dA3Jb0AkrhdnMh9KrmFG33zDlyD4WLwbotDxLy2PBTl/n8veyiSOfh9iwp1qZULH0VuYj6Wu3kdRaadN1DeNkqpV6Vwa5MApE98XiN58iAEqZ+FLzki6j8GXwq/GSGvSNMXS6LA0x/RMuIv8CMPmKnQGa+taYHbLtCZw8wGChnttJC3BKjrJcPrJ+uy/hjJnSAAdUOJBzANrn087qVtdT0a/M4acDxlaftDZBXkzKAG+GlH8eK0rHTH0fRZHo0gQr6ndXPi9GQuVOwo8RyTu7QWXADEN9IOtFLaT9gbRUIUXdUN1GhszD3ZVM2PeAJBxpF8WP+gP9hePg60AALQct5ESryRZUVcqoXk1hBxhPXZQM/Eiwl7wQ7qPXJemCjvsxD5DsySx5tKIJRT1ZpZIiVtgQX1aQ3tyaIdHNtePWdKcIKe1NGAzt71IKrNw/acxnPYYjeTO9v7iyaw06L7jEUG2ojWNXCMagBdE0/kJMZpZU2ZBImNfHXsCPmjSR/WerIoY0sg93MtWYr2Ds0H64nd+ChneCcWfcrAtq6SUDbBV6GsgUMN6qp4jhoMUQ/Z9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR01MB7452.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230031)(396003)(366004)(346002)(136003)(376002)(39860400002)(230273577357003)(230173577357003)(230922051799003)(1800799012)(186009)(451199024)(64100799003)(75432002)(83380400001)(26005)(71200400001)(166002)(41300700001)(54906003)(122000001)(66476007)(52536014)(64756008)(66446008)(66556008)(76116006)(786003)(316002)(5660300002)(2906002)(8936002)(38100700002)(4326008)(66946007)(8676002)(7696005)(6506007)(9686003)(91956017)(966005)(110136005)(478600001)(53546011)(38070700009)(86362001)(33656002)(41320700001)(55016003)(66899024); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?5IfdjAxEN15fuy30HiTFsMSGbqMdoXOkp8Gi1DOfMybWM22jDHCPZSDT?= =?Windows-1252?Q?uO1TTsCYvWqzMXQGZdp/oedh6hJKCwJqPfHffygkQfNIVPR8Sb6x0KoU?= =?Windows-1252?Q?Sd2Pw2f7W1+K7aq8eLpRb0xQkzAh4Lg+gVKyzjZxBWwZta9njmPXouya?= =?Windows-1252?Q?bH2pXh7ehkXpHZUuNQ3W5AunIkLnJUI5eTtdBqkOLvwKssWnD4XBSs9X?= =?Windows-1252?Q?WYOR2QSHzoP/5o1ivVVGTFQDrLG5j/d3jrYsh7d4E0i9+vR2mGvkEG4W?= =?Windows-1252?Q?nrutztorjdukV4zXCxFPNvPXcznwhXgJL73A9GCJgMqhN/nhRmiSzJ1b?= =?Windows-1252?Q?GOiLZ4ecXSJCb1YSGc8L2SmKGAII+zcBPbSbwvd2xSHLKfOcs6BZHZCR?= =?Windows-1252?Q?wHaU6ZEPh+PmW2Hcs+sCQy9XjdJtLHL641+BD0hxCaI+cMWXcz7Q3bQ2?= =?Windows-1252?Q?fiQePAso6BeYIOOlQoNPO6WdwcJWgdo2fjLkiX5t8yo0br0Lw+hhNyRy?= =?Windows-1252?Q?+ItMdB/v6blJ8ZSQASMcAU0eQGQ+fb2rY4K/hngCPfvVUfGE40XZX8eD?= =?Windows-1252?Q?DCX5nIGi5YR9/yoB0DtUQM/UXOJw8HBFbmbJVtJJnINJrq+wafGxPt0K?= =?Windows-1252?Q?/i3UrBIMJVbla74V1QtdovuSwEqF7970GJOM+yLcExdRgQeKvXN80J+c?= =?Windows-1252?Q?qxGGjR+sqR9VFZeW7NKL3BYKvnkYhxplqrl2s8XvVd1n3sg0e12MzD5D?= =?Windows-1252?Q?i6hBD3O0uo4pWXIwIIPljfOdO0Zmk/8KbGkI3F/WGHvfShpxHNb7ZepS?= =?Windows-1252?Q?IfM0NiOE5lfw67sEcpqRbru6y180iN907cm3nZ1JdVhmBRT5E4g2UsNJ?= =?Windows-1252?Q?WIpR1aJzFT2xMXBC3ruxvbIA1qpj4Ik6O9HI32V0G+BaU12YjdS1LBTs?= =?Windows-1252?Q?jbTPdFXJjc4PPJrtpyaQcwZw63YUpdvGDnWU/e4lcNQ8ffOjtK5cmlb4?= =?Windows-1252?Q?7XRXdXx5G9LVssLHbP5oAqY1gX4as2EEbg+x5UtE9M7L33rvvnZ8Bm/Q?= =?Windows-1252?Q?jtSNNebaMsQfkFYoRAFEizmNTLpCqi0YAmnbfh5EW3HK/biw7A0g5JTQ?= =?Windows-1252?Q?NWZBUtWtXTx94qEUMpS+H3cz4BERaeC1tOHTxr+uZhkqtSzS1zIEq3yS?= =?Windows-1252?Q?fRvsnQWYuKI9th0xnhJQIxDHVhAdR47ErQYPIkQCfsU5ujGO7u01fpQ/?= =?Windows-1252?Q?xWvqKyEi+Ywr/XZo4/rTNqE3RbpWRHp3vUYaWhTFs/mmKvQI5vi+ScPQ?= =?Windows-1252?Q?8By5c31PI2xlgn6XEvt0UEgHKeLRboVx2PC1RR1Zmsc61NQZgnM7B68Q?= =?Windows-1252?Q?vxE5JyWszKgjGFfZv7jsO0s552e6i0DrgQ9V1VpPuKQt+IELMtdZEJ76?= =?Windows-1252?Q?JWPU/4SjLxWuWwJFEPybWzlIUUzGLOapDQM4Dtb7o7SvOMjCQMYa+Jdo?= =?Windows-1252?Q?szg2jd/DE459sAEWQ/TZhCEvKBwfliwog1IkVvXa2fQVLIFPRMJJzZc2?= =?Windows-1252?Q?1YgeS7gVnpMiT5Xfb0pUjS4LmCayUvTVjiO09adqnAosGio0zeWE6RSo?= =?Windows-1252?Q?Dqd+QWB9hXdKR4RvdEadcfZouUbK7eUXk9rDU0br6IQxhCjQ9p1aVvvT?= =?Windows-1252?Q?C0f3lgI9vjV7LysrdMtYENsRr5GxhWtpjT32wBHd3VDvCJ81nK7jHQ?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CO6PR01MB74524A264F6698EF838E1C3CCB692CO6PR01MB7452prod_" MIME-Version: 1.0 X-OriginatorOrg: mcw.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR01MB7452.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: de62b6c6-6c40-43df-373a-08dc12106241 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2024 19:14:35.6380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9963652a-ab0a-4f1b-994a-b49e83d90f0e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K4fn1yqjwCLawE2frdZyavKy52aKT0LEMHXGZ2r3+NPGEg10lQ7QCuxJoCRZOF/P93J4FdOlP0mNzUtP3KZhmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR01MB6823 X-Proofpoint-ORIG-GUID: 5x_1cP3XrR4Z4S8mpcugZ5zYkO4q607H X-Proofpoint-GUID: 5x_1cP3XrR4Z4S8mpcugZ5zYkO4q607H X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-09_01,2023-12-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 phishscore=0 suspectscore=0 bulkscore=0 clxscore=1011 mlxlogscore=999 malwarescore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2401100152 Received-SPF: pass client-ip=205.220.162.138; envelope-from=rsparapa@mcw.edu; helo=mx0a-0021c101.pphosted.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, HTML_MESSAGE=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-Mailman-Approved-At: Fri, 12 Jan 2024 08:42:13 -0500 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-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -7.90 X-Spam-Score: -7.90 X-Migadu-Queue-Id: 20B5275CEC X-TUID: g1dngc9RnRw8 --_000_CO6PR01MB74524A264F6698EF838E1C3CCB692CO6PR01MB7452prod_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jack: Do you have a patch? I=92m not an org-mode user so I can=92t test this mys= elf. 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-core@r-project.org Cc: Liu Hui , emacs-orgmode@gnu.org Subject: [FR] Add buffer-local setting to request specific ESS process/sess= ion 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: https://urldefense.com/v3/__https://stat.ethz.ch/mailman/lis= tinfo/ess-core__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJe= RQ_nskag8V97kuVRUbqj41mRZtQD1vycT2vdFw$ --_000_CO6PR01MB74524A264F6698EF838E1C3CCB692CO6PR01MB7452prod_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Jack:=

 

Do you have a patch= ?  I=92m not an org-mode user so I can=92t test this myself.

Thanks

 

-- = ;

Rodney = Sparapani, Associate Professor of Biostatistics, He/Him/His

Vice Pr= esident, Wisconsin Chapter of the American Statistical Association

Institu= te for Health and Equity, Division of Biostatistics

Medical= College of Wisconsin, Milwaukee Campus

 

From: ESS-core <ess-core-bounces@r-project.org> on be= half 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 proce= ss/session name (was: [PATCH] Set Python shell in Org edit buffer)

ATTENTION: This ema= il originated from a sender outside of MCW. Use caution when clicking on li= nks 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*qs7xAeP7B= emu4ThM4-oGJYxxD*K2jAAw-w7RHtX2gQ@mail.gmail.com/T/*maa33e7c3f72b5c81deb91e= 1a1d27d57725097fa4__;Kysj!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30= OuWfzKJeRQ_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 create= s 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 s= eems ESS will always
> assume you want to evaluate in existing session if one exists, rather<= br> > 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<= br> `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*&quo= t; does create session
> "*bar*" with correct name.
>
> After sessions "foo" and "*bar*" have both been cr= eated, 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 suggeste= d)
> to explicitly control the startup behavior (either to auto-start, or n= ot).
>
> 3. Submit PR to ESS to add a variable we could let-bind, to force it t= o
> 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,<= br> > 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://orgmod= e.org/__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag= 8V97kuVRUbqj41mRZtQD1vxMkIQ3lQ$ >.
Support Org development at <https://urldefense.com/v3/__https://liberapa= y.com/org-mode__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJe= RQ_nskag8V97kuVRUbqj41mRZtQD1vzCeD9KoQ$ >,
or support my work at <https://urldefense.com/v3/__https://liberapay.com= /yantar92__;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_ns= kag8V97kuVRUbqj41mRZtQD1vykpYx2Qw$ >

_______________________________________________
ESS-core list: https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/ess-core_= _;!!H8mHWRdzp34!4Q2jIK3jwVcEOegQ2fIC5apK11fdrSkufT30OuWfzKJeRQ_nskag8V97kuV= RUbqj41mRZtQD1vycT2vdFw$

--_000_CO6PR01MB74524A264F6698EF838E1C3CCB692CO6PR01MB7452prod_--