From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id wAz4DfdBoWWBdgAAkFu2QA (envelope-from ) for ; Fri, 12 Jan 2024 14:43:19 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id WA1tCvdBoWUVCQEA62LTzQ (envelope-from ) for ; Fri, 12 Jan 2024 14:43:19 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=mcw.edu header.s=11132019PPKEY header.b=XNcbrDrI; dmarc=pass (policy=quarantine) header.from=mcw.edu; arc=pass ("microsoft.com:s=arcselector9901:i=1"); 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" ARC-Seal: i=2; s=key1; d=yhetil.org; t=1705066999; a=rsa-sha256; cv=pass; b=Sl5ayqXxvvh6DW5mMAilAfC5z7DhkG0n7gq1gMmnbdfTckD9oojwrcGDSfFfpQ/SN5FHvm 5SrLTnOoYQog9m4sKTD7PVuOb9CT0VrTEQin/MubF0Dwp8HU9S04rce9wjrr9pWeOvsCwN X5pRdPkxtfqHxf5OLR3nx3y+eCXjkeRi+ySG7kJAcm7aa5X8W5PiNuiPG6vovRNff4uZdg Wf6Zt9mu7I4wuc3ppF34VeHP05Q6WE2Tkg7znjyAcdW3hAL/Z+25LHQ7N7+XKaZRn7iSxt U6d2C4a10bvXKxSW6ZTGn3rWO/THlO3EBLCs67vacvo+9ZKGJZaqjjjYF2TjqA== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=mcw.edu header.s=11132019PPKEY header.b=XNcbrDrI; dmarc=pass (policy=quarantine) header.from=mcw.edu; arc=pass ("microsoft.com:s=arcselector9901:i=1"); 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" ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1705066999; 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=EGiRyiFxIhd9Sicg1iX+I63NtqwVHMlW2UNm1A6NVT4=; b=gjAw1ebjEY00moxbIRmOSveYCuM89GfKqDLCfcWf+YIGqk0lPklV0ln4MQbFCoTHioYqYo f9djMc00Maiy+ky6uAf4stSkeUvgdIYLfHPG7fJdoLSjLz6L3X4fYJj9k9AR6Ltm2YdKH5 AP9MyewS/B418DRWmesdC4TJcb+u2RWif51k0QiBZMVnpY6eAHku8Soillad9c5zkzDG1M icMDJ7bWLkypHCRihuSc6bNpHdwzC/gNFJlfemcgB9qdGgL7Rl76kQPVwUd/SOZo3EMSNs XUHKrgZUe7LxxoGghFEpzCMyoOQ7W0tkiZrgCUYEa/M5LvgqtKQXfNwdPVos3Q== 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 5D5693702B for ; Fri, 12 Jan 2024 14:43:18 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rOHnb-0003TW-5r; Fri, 12 Jan 2024 08:42:15 -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 1rNe3L-00048H-MT for emacs-orgmode@gnu.org; Wed, 10 Jan 2024 14:15:51 -0500 Received: from mx0b-0021c101.pphosted.com ([205.220.174.137]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNe3I-0008Ca-MA for emacs-orgmode@gnu.org; Wed, 10 Jan 2024 14:15:51 -0500 Received: from pps.filterd (m0195927.ppops.net [127.0.0.1]) by mx0a-0021c101.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 40AItbA4021867; Wed, 10 Jan 2024 13:15:46 -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=EGiRyiFxIhd9Sicg 1iX+I63NtqwVHMlW2UNm1A6NVT4=; b=XNcbrDrIBQ6M3cBKnZuUxaYpFWEUjLWo AoWwIy1NEG/hjHLId9CrqiBI1k7XqFAzSYqPncIpfIChV4B/Msf9SZ7DdMt68JOk sh3RfXb4DdTqWGTU6NUerhIi+oh2OKsjOD/ReXAgdxnXImxpjEp6rlz1U7VmNDCc ll8Y8iS1+6uXVy3Tlgsh2I8RHfbylA6XbLllFcFpzX3pLAJGvOYn/T2enh13RZVO +qdLHglXwcbE2OZINRlcWSWxjW1qJtM2STWeRHWaYOhRGcwY4pURJLlHCx7cKe8H 1bjygWGL73aNoSdxd1IixFsX4KMUm8Zg7g/bcysxQXKFDSe4DwBs4A== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169]) by mx0a-0021c101.pphosted.com (PPS) with ESMTPS id 3vj0xr03af-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jan 2024 13:15:46 -0600 (CST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AQo11VBbyaL50sE0eZbhUdXoejSq02T29+kZelcXN7ES8uOi7UTeP4lnSNC69viEMLaR378FRE7ROES6DILbs+KxHJk9JyjQEW+ZeJIDhJeAwF8essNFaarAffRG5M/0g5iwA/trfTaHp49P2efqd79euO431NhnJMKXds81SI3WB4UYv53o55AGZFUMFRXTirEtDr9ZAtJDyg3/VBHrf6I6mOsGVMigH62O5iEyVzVq6WHin98u6FZzOhy8FhglZ3r4YWwvvFMpoSOlNQp1T/EGjTVeeuD/SuOZct4ouHDPwiASInRVj9usiN0SzrFSxsWVBWkqZNHals+5pcv0TA== 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=EGiRyiFxIhd9Sicg1iX+I63NtqwVHMlW2UNm1A6NVT4=; b=NjQarDXZ/jWoLyKgVdkRm7+XloizWBZCsjy92OROl9q0mteMf0cOUBD3ikswZpS4NDYDDPRKC7P/wmTGy3Gvel5zPQ19v2L4jHpddk9m+7afipI2bua7PZ1xSUtDeKtFIF05jZR20LgW7IvxIRPf89PBc1+YRL3hjh1cXNp5yPlQOy0HzoRRTW/DbV+yOuUmweB8r+IW2wg4yicOMHqaGwIxsQ4rYoAd5GeO3hYNcFHJYc7LSTWh2wgxvEMgldgvPft1DBSnSu8+49PxOE8qsbcYpSUToowzJIdy0xa/fLPf75RRin5bPbeRrS0Blo+KPhBvKP/QLgL4czej62m3iw== 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:15:43 +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:15:43 +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/iEeozuE1PrDTarvagAAAXWk= Date: Wed, 10 Jan 2024 19:15:43 +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: 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: ead23ce3-d6f8-4649-f576-08dc12108a90 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cJqTxEFfXxm7YIGwzmgoQL2aLViESHz4Igs5TClyz867+ovf+asBRhM3ODysL1Mj8nB0ADxBCmnu58v0mQ7r0h2loJ7a7yDXHJ5TzEbHDANFuWkcqFCU2JInam7OM8mQGz+E1QzaTnLH5sb4Ig7/ui1N/AXshhDfM+uewO7ZqPdGN52t3CLCOwhLYZ+bFU7lBYW1X3zlc0dUyBHcDIh1SMEUB4MkAe5x3+N2bkqqYj2mbjbMmxHtmrf7hdM+XyaQWrncFaXtRJAzdYSC1yCEVaDkSpFfXMc0JulpEUZQkidPdiycr5UkwQYNRZ51Av32G5gVqm9CV8xqSjuwHFClJKUj0cWqyZmbWY6NWM6pHuYXfa756tw1OvaZsYrh5W2dle6FxldLKWycHSzKrVTwtz8a1/RRnJyWaLJE/TtOvyiuV2gy+1wUDaqUpoJzWPGyIIAtAbmSsAO86YQEEJKiL67k2qqcwOMHmiabL/LA0e2MFUXOSWrRYK7KhTdG5EcA9301jhlwZQWN3EIVOhfRG/F9CPB7P8LAWN/VMZpKLfEwIYRsDm+35l1hUKYNOROXld9mXxkqkXIseVt6tiatWMHkwy/JMgM0Bkyw0Ujvf/aS5uOmvlxiJzRwQkLWfHRDork2UKfcQYJESIViNppWog== 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)(2940100002)(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?7jztYtehg3QwdOGDG74gqaGcyEHZPW2YZ0NZ9Mgm9SmBL9ebDpWLoVxg?= =?Windows-1252?Q?LBsCx+P7a99JNhUgO1ngoJ+TifCfGF4F8GaK/aMoEwnspSG0tRyBvIle?= =?Windows-1252?Q?lakTRncmnxayOaI7ZUJZX4X+7gBPYUjTPj5dfPZC7UP0Xgqafm8yX8FA?= =?Windows-1252?Q?os3k+Tab/4Kv/CmoACCcVUeeO47WhLz8yLO+f3gb7QhlVR1+mdruaT9F?= =?Windows-1252?Q?aYcGF5kjQGSo4ojP/Yy8dRQ5DgKlklG9dUFni04Y5zQwlGTNbBc3cnLx?= =?Windows-1252?Q?KakB/fCY50HdtcvQstO47HBlgsS/rjdzJsALrQfh34HXVyxrTfHOqn6Q?= =?Windows-1252?Q?JW1Vr/R0KPu2vE1SQWCwnlF2NKXkhoWkDB5wx7S1uyGKqfjpV7EmFRTk?= =?Windows-1252?Q?wRDEwrRamOro0on18WCEUqzMREgs9j5NzWvBL/qAL2k7+C1ypaf2Ocqp?= =?Windows-1252?Q?u3U/O1LDofT3O7CxAsfC88muwQD5Q/2qtdQp9RECLxsFYEPtmbcv5MF1?= =?Windows-1252?Q?LNTcOH7WOvpJcPa2hjF3SSTrbLjNRfld7/+HC1rF5OSzTU1DS7K31l8F?= =?Windows-1252?Q?4KtEdU1oYK8s7voupe3ZIw5u81xVWTZZXsn6oxKpq+YtKPqrl7x/SKNe?= =?Windows-1252?Q?qtHeLbKOd1obST/KOohUq8epAmImVwRz7xdHToOn7NUuzas4KPwushAy?= =?Windows-1252?Q?fyhWU7o2bfMGr7+4ocFlz6m1OfD64H1Hv4d6e/qEN5DtfItRZA4H8bja?= =?Windows-1252?Q?aQrFePRSTFISX/Y6SZXI9YpIaTlUNSR9+joY+CzJI8nrPmEN80/3aKHj?= =?Windows-1252?Q?W791HoK01OT6nLvCRWur7igj++X1JgmqvHQZnwguA0iOixIQEfp8WgJX?= =?Windows-1252?Q?Eg8BgYw8SlPbpMhJhB3RzdqhDihX6E/VqjUVSyV35gdwnxtA+Usy8Wl1?= =?Windows-1252?Q?ILeKQgbBXCmM/AL9xqKB2EffBvpUB35maewbDDvko51bf/5Ug4f/mbvT?= =?Windows-1252?Q?owrm/ka9eh+WD+lcA1rGCRrpYQ2Kn5ayUjxEooppRnVd6R7LQKP39ZZt?= =?Windows-1252?Q?lXQOE3TlzwFaWcyoVHkgUMrLdZYHhq195VE21+WWrsEiqFszfYZqeo9j?= =?Windows-1252?Q?TpOFQK1Tx/16N+U7CH3a/rEzSzkf5LYm1+8+Vyc5NolApPrzlOSxkBHl?= =?Windows-1252?Q?WKj5N048YndrMLA+Rj4dJCHKfZTmFlgznETlq4Q0H6thvwhquCMlftvT?= =?Windows-1252?Q?6zfUkcYdbMDgd1GZ6cHuUMw1IjwJi0AAmARJU/mq89I7yv15tu8dHeF2?= =?Windows-1252?Q?Lt729rpcVtatmmQ5Kw+fp0j5Pc5tRSSem58AkiJ0onUSbyAE0qBW9gNH?= =?Windows-1252?Q?zTnFXk/YSOQQCbl3WqNc2fvyN/BE/sC02pWQoKmwS8alB4y7BP7xVG3T?= =?Windows-1252?Q?efBEwLH34Fg+QmDUzfKx82zqaK4QY5YE5Xf6c7NisEii6rZyCbXNwc7d?= =?Windows-1252?Q?35gPdPXurErW2K2zMC/UF4x9RJMPYfbgw8cTSMNZFREBIMPGTnehwCK1?= =?Windows-1252?Q?sTdMjkeFzynow4YBsyT5YCPqiP4sVFsUyqVXY8BHMcohSluxktDsLbKI?= =?Windows-1252?Q?8tIdLiv7GbhKYBaPBu+qWoKZlGbLGdO71KX3y0/h7ae83Fp4fSOpYm+H?= =?Windows-1252?Q?3T3eJ6uYVGQYX2sp4bx1EWJMUTHdOMudGUlReDMdRv/H9L6JB9EB+A?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CO6PR01MB745259ED606FE0B5B3FF4FCBCB692CO6PR01MB7452prod_" 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: ead23ce3-d6f8-4649-f576-08dc12108a90 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2024 19:15:43.2691 (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: aW0dXGq4rNCOoSgzsFkOYGVem0kiYIzDI7dqYckILSuUb/Xx6VUp/CcjHz5xPSJ7ygsRLCPkWgLW9WKEMFW5eg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR01MB6823 X-Proofpoint-GUID: aWsV8hRGjFISu4Bmy8lmeDU_y3faCFen X-Proofpoint-ORIG-GUID: aWsV8hRGjFISu4Bmy8lmeDU_y3faCFen 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_02,2023-12-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2401100152 Received-SPF: pass client-ip=205.220.174.137; envelope-from=rsparapa@mcw.edu; helo=mx0b-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, RCVD_IN_DNSWL_NONE=-0.0001, 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: mx12.migadu.com X-Migadu-Spam-Score: -7.90 X-Spam-Score: -7.90 X-Migadu-Queue-Id: 5D5693702B X-TUID: ct4ZQBvuoe/5 --_000_CO6PR01MB745259ED606FE0B5B3FF4FCBCB692CO6PR01MB7452prod_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Oops! Sorry, I misread the signature. That should be=85 Hi Ihor: 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: Sparapani, Rodney Date: Wednesday, January 10, 2024 at 1:14 PM To: Ihor Radchenko , Jack Kamm , E= SS-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) 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_CO6PR01MB745259ED606FE0B5B3FF4FCBCB692CO6PR01MB7452prod_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

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

 

Hi Ihor:

 <= /o:p>

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

Thanks<= /o:p>

 

-- = ;

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: Sparapani, Rodney <rsparapa@mcw.edu>
Date: Wednesday, January 10, 2024 at 1:14 PM
To: Ihor Radchenko <yantar92@posteo.net>, Jack Kamm <jackka= mm@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: Re: [FR] Add buffer-local setting to request specific ESS p= rocess/session name (was: [PATCH] Set Python shell in Org edit buffer)=

Hi Jack:

 <= /o:p>

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

Thanks<= /o:p>

 <= /o:p>

-- = ;

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

 <= /o:p>

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_CO6PR01MB745259ED606FE0B5B3FF4FCBCB692CO6PR01MB7452prod_--