From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Danny Freeman Newsgroups: gmane.emacs.devel Subject: Re: Eglot, project.el, and python virtual environments Date: Fri, 18 Nov 2022 08:55:35 -0500 Message-ID: <87k03swcye.fsf@dfreeman.email> 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> <838rk8d7xb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20974"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Phil Sainty , Dmitry Gutov , theophilusx@gmail.com, emacs-devel@gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9y?= =?utf-8?B?YQ==?= To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 18 15:33:28 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 1ow2Qq-0005Gw-It for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Nov 2022 15:33:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ow2Q9-00033P-3d; Fri, 18 Nov 2022 09:32:46 -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 1ow2Pw-00031A-2Z for emacs-devel@gnu.org; Fri, 18 Nov 2022 09:32:35 -0500 Original-Received: from out0.migadu.com ([2001:41d0:2:267::]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ow2Pk-00039I-K3; Fri, 18 Nov 2022 09:32:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dfreeman.email; s=key1; t=1668781937; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IbXDtNIeQyzfwxwVJr1RjDxGerHhajy6+5nfV0agQU8=; b=SB7/oqnYdSn9vk/MmfLXJSy695yQABU8P+kfNP1mVJ6JrzinH/aq8dnLIH//5dkdLUsH2P e23RFsZR9Jyc7fKF371dwB7LRSt0PDt342grtsDYhxTz171quPjoCUiCVGtszZJSpZwFQ4 gG6W2kw0zXmhnFwXbuAsJO64gk4Mu8E= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-reply-to: <838rk8d7xb.fsf@gnu.org> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:2:267::; envelope-from=danny@dfreeman.email; helo=out0.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:300106 Archived-At: Eli Zaretskii writes: > 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 think that most monorepo projects fall into this category. That is a large version controlled repository with multiple sub projects in it. Sometimes the subprojects are written in different languages. Usually there are sub folders of the monorepo project that act as sub projects. I ran into one at work yesterday, but I'm not sure what I would have project.el do differently there. I preferred it's behavior actually.=20 > 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. Is this not exactly what `eglot-lsp-context` is for? Using my example from earlier in the thread is what I suspect is the "right way" to solve this: ``` (defun project-find-virtualenv-for-eglot (dir) (when eglot-lsp-context (let ((root (locate-dominating-file dir ".virtualenv"))) (when root (cons 'transient root))))) (add-hook 'project-find-functions #'project-find-virtualenv-for-eglot) ``` It can be made more targeted by checking the value of directory if necessary. (I could also a use when-let) It is an obscure way to solve this problem. I only know about it from my time spent with eglot's source. Not every user will have that experience. How could we make that better? > Another evidence that this should be solved in Eglot is that "the > other LSP mode" doesn't depend on project for this. The other lsp mode solves this by prompting the user for the root directory where the lsp server should start and remembers the user's=20 choice. I'm starting to understand why they did that: it handles a lot of the cases like this where LSP root !=3D project root, but I think we can do better than a prompt. The majority of the projects I work on lsp root is the same as the project root and I like not being bothered by a prompt. I would also be interested in Jo=C3=A3o's thoughts on how this could be handled. Copying him. --=20 Danny Freeman