From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Eglot, project.el, and python virtual environments Date: Fri, 18 Nov 2022 09:43:28 +0200 Message-ID: <838rk8d7xb.fsf@gnu.org> References: <87zgcq68zp.fsf@ericabrahamsen.net> <878rkale3l.fsf@dfreeman.email> <87v8nezf2k.fsf@ericabrahamsen.net> <87o7t5k7sv.fsf@dfreeman.email> <86mt8p4221.fsf@gmail.com> <4cc918a053771a5e1c440cb4b458f3ed@webmail.orcon.net.nz> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37099"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, emacs-devel@gnu.org To: Phil Sainty , Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 18 08:44:19 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ovw2s-0009PL-JK for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Nov 2022 08:44:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovw28-0005hw-28; Fri, 18 Nov 2022 02:43:32 -0500 Original-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 1ovw24-0005hb-4Y for emacs-devel@gnu.org; Fri, 18 Nov 2022 02:43:28 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovw22-0008GQ-Q8; Fri, 18 Nov 2022 02:43:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YW3iNd7mhz/SBnx2aY4sj02x+WRHoeL3RFQlq0sgX+I=; b=VGFUeC0OmK8d v1p98JFhpJle3pGFdmKjCu7oq0iItKOfj/inHyhaSZ1fxAf/cBUnz+LV759y9PvK86jBHbavhE4XR AF7ppuJ0SwGJLfLs3Rvsiwogk7W04Av1hns8Uoy8ePWFq05A8eimIknHpBfdzXUVBlwtb9MbyNLxy bh6YXf2tVIsa4U4fT4Y+yfMrDVpv+h4/4C6Us1q+18hACtxkBIKsTmTDqhm7ITCQQcISr/7D5iO/P UAX1ljdxQt2CB/UNTOPMdFPpOdiCgR19bTmnldC7jG0x0Yjig/jpig2sB/oYq0KHWHV+MvgvrKJUU HQT4PJhyc5DbR0k3DtoaIA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovw20-0002U0-TY; Fri, 18 Nov 2022 02:43:26 -0500 In-Reply-To: <4cc918a053771a5e1c440cb4b458f3ed@webmail.orcon.net.nz> (message from Phil Sainty on Fri, 18 Nov 2022 15:38:34 +1300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300092 Archived-At: > Date: Fri, 18 Nov 2022 15:38:34 +1300 > From: Phil Sainty > Cc: emacs-devel@gnu.org > > > I guess my question here is whether the focus should be on enhancing > > project.el rather than modifying/enhancing eglot.el to handle this use > > case? > > It seems to me that while project.el could acquire the notion of > sub-projects, the *meaning* of a sub-project would be entirely > specific to the tool which needed it (eglot in this case). And if you > had multiple tools which each wanted some kind of sub-project, you > might find that some of the sub-projects were overlapping others, > depending on the needs of the tools which each one was related to. > > Still, if eglot could ask project.el for "the nearest sub-project > defined for 'eglot' usage, if any, and otherwise the main project" and > project.el had been told that for the project at /path/to/proj there > was an 'eglot' sub-project at /path/to/proj/subdir/foo, then that > could be useful. > > So project.el could provide an API for defining and returning > sub-projects, but it would be up to eglot (or other tools) to cause > such sub-projects to have any kind of effect, and it would be up to > the end-user to define their 'eglot' sub-projects in the first place. I think this turns the table for no good reason. I see no reason to add complex new abstractions to project.el just because we have an issue with configuring Eglot in the use case presented in this thread. Let me remind you that Eglot already supports a kind of "sub-project": it uses the same LSP server only for those source files in a project that share the same major mode. So parts of a project that use a different PL are already considered to be a "sub-project", and Eglot does that without any help from project.el. Given that this feature already exists, a proposal to add a "sub-project" notion to project.el should describe at least several use cases of such "sub-projects" where the separate "sub-projects" share the same programming language. If the situation with python-env is the only one we find reasonable, IMO adding "sub-projects" to project.el is an unjustified complication. I suggest to look at this as an Eglot issue, not a project.el issue. What is requested here is an ability to tell Eglot which directories should share the same LSP server and which ones should have separate servers. It shouldn't be hard to have a buffer-local variable to tell Eglot that, or a function that accepts a buffer and returns a value that Eglot can use for this decision. All we need is a way to tell Eglot which directories to communicate to the LSP server as those which it should watch, and when to start another instance of the LSP server even though one is already up and running for this project and major mode. Let's not complicate project.el for a problem that doesn't belong to it. Another evidence that this should be solved in Eglot is that "the other LSP mode" doesn't depend on project for this. I would also like to hear from Dmitry what are his thoughts on this.