From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Eglot, project.el, and python virtual environments Date: Sun, 20 Nov 2022 01:51:04 +0000 Message-ID: <87zgcml7g7.fsf@gmail.com> References: <87zgcq68zp.fsf@ericabrahamsen.net> <878rkale3l.fsf@dfreeman.email> <4c5f4b07-3df6-d700-83f8-9a9d1b684afc@yandex.ru> <84781346-5b88-2be5-38bb-02696fcf1364@yandex.ru> <87o7t2vj19.fsf@dfreeman.email> <877czqtyfy.fsf@dfreeman.email> 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="38741"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Dmitry Gutov , Eric Abrahamsen , emacs-devel To: Danny Freeman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 20 02:50:46 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 1owZTp-0009tc-GO for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Nov 2022 02:50:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owZT4-0004Gq-UA; Sat, 19 Nov 2022 20:49:58 -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 1owZT3-0004Gi-F4 for emacs-devel@gnu.org; Sat, 19 Nov 2022 20:49:57 -0500 Original-Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1owZT1-0007aN-Lj for emacs-devel@gnu.org; Sat, 19 Nov 2022 20:49:57 -0500 Original-Received: by mail-wr1-x431.google.com with SMTP id i12so11103170wrb.0 for ; Sat, 19 Nov 2022 17:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3c2Hq23KN4PjLjsG0LzPsz2lBlQN5xjDa4VufCkjMzg=; b=J7zSGJv3cHjxy0ymnW5RETM+t2FzEBWXnR3c/MAK1Aen4F5ts6rVkQSdgPdYwzzYEp YwTFccGkMEsxETDVrZqkyVuGGPyg17XYKMzvbFCSE3t+okH0lzevVxsJiy4S0H4Vyw8k r2HqW6AZ1WzXadfBEA142TxtIzhcg7epRexf5mIff2Ez8GcTKzkBUKBZRpcc6SK55vAg vAeiJJ1L6W4AZdJEAlH5/tl889A95NqcdLEsPx3H5Vs7ToFqWu/8tqR3OkY6J9wZhl4v czOuXL8XnIbZx6hvhkjAbFYYVqlRducRdO/o4949nlOy52eZ6PRsFfTqkGYNFDadBhsf h5cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3c2Hq23KN4PjLjsG0LzPsz2lBlQN5xjDa4VufCkjMzg=; b=PdiY/5TDcHJNJZMvjKU60+84cQHicyTvzaWvRP5CxEBUNzbWQuSvLAdCelJmSudqh/ ZV16Hg+dIiOhI/pNBGquNnkaTJc00vtpiLXdIMJ54lgAFy19Hb3hjQ9TFHQEcEdKSsc7 KXeVUbDip4rtLC0wqqryYmbVpWCB9ayZKQL6BmIvJfxXHJpv7XyxLsv8xcNeaYJ6j1Tl //yqr64cm1ONHIy3Bc15AoVskHBNv2OAjW84m+EP+d30s5RGAdHMdfhOFY4uP7iSbv68 3uT6ZjTftuMWA6OhuGwedzRf/j9caeY9cqsC+7/OCv31bbebaSTpfuH5OOqmn5GbhsK+ 4yRA== X-Gm-Message-State: ANoB5plyFpaK05OVPvKgLs8Xz4NqzLyD0vSU3IMyAH/rB+EViE7ZCEx6 lYxdX0f6rUoGrEQqeKxWMfuZt8S1A1Q= X-Google-Smtp-Source: AA0mqf7teANLz5jOyNiL5HbDyceG1xBlV9hUCVriTyfzjfKGH55jBaccu7lBx7Wv4/OXltgOg0GSaQ== X-Received: by 2002:a5d:51ce:0:b0:236:78cd:f3e7 with SMTP id n14-20020a5d51ce000000b0023678cdf3e7mr7379696wrv.140.1668908993700; Sat, 19 Nov 2022 17:49:53 -0800 (PST) Original-Received: from krug ([87.196.81.1]) by smtp.gmail.com with ESMTPSA id iv7-20020a05600c548700b003cf87623c16sm15882344wmb.4.2022.11.19.17.49.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Nov 2022 17:49:53 -0800 (PST) In-Reply-To: <877czqtyfy.fsf@dfreeman.email> (Danny Freeman's message of "Sat, 19 Nov 2022 16:22:28 -0500") Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x431.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:300223 Archived-At: Danny Freeman writes: > Dmitry Gutov writes: > >> Then your solution should work okay, but it also means it belongs to the= category of Eglot hacks (as >> opposed to project.el hacks). > > It is absolutely an Eglot hack :) I don't consider this a hack at all. Not only does it work okay, it's how supposed to work. Dmitry has often suggested an Eglot-specific project.el backend, i.e. a new type of object to specialize project.el generic functions to, but I think that a good idea: Eglot is not a source of truth for project information, like .git directories. Instead Eglot is a _client_ for that information as gathered from via some arbitrary method that Eglot is angnostic to.=20=20 The information is forwarded to the LSP server as the "workspace", but the user needn't ever hear that M$ lingo. So I don't think we should invent an second notion of "LSP Workspace" into Emacs via Eglot. Personally, when I tried lsp-mode a long time ago, "workspaces" was a confusing concept and useless to me as a user. Emacs users should just think of "projects". Most of the time, the default project-finding methods bundled with Emacs work extremely well, in fact so well that it seems almost offensive when they don't. But it's crucial to recognize that this is not just because of LSP reasons. For example, simply because of the relatively poor performance of the default project.el VC backend in a gargantuan repo of 400k files, I've had to define a different notion of "project" recently. What constitutes a useful "project" for a user's setup can indeed vary immensely. So project.el should grow to address these corner cases, maybe inventing new abstractions not tied to a particular client, including LSP. Maybe both this Python venv example and my "gargantuan repo" example are hinting at possible uses for a "subproject" abstraction? Just food for thought. > (defun eglot--find-lsp-root (dir) > (when-let ((root (and eglot-root-marker > eglot-lsp-context > (locate-dominating-file dir eglot-root-marker)))) > (cons 'transient root))) > > (add-hook 'project-find-functions #'eglot--find-lsp-root) I think the code above is fine, but it belongs in the user's configuration. In fact, it belongs in the manual, in a section similar to what used to be section called "Handling Quirkly Servers" in the old README. This code doesn't belong in Eglot. Eglot is designed as thin layer making different Emacs facilities communicate with LSP servers. Eglot's user interaction is mostly for LSP basics such as connect/disconnect and Eglot's user preferences deal with LSP in its generality. Baking project definition facilities into Eglot would bloat it and I don't want that. Are we worried that users will find it hard to apply snippets such as Danny's? My experience with libraries such as Yasnippet, SLY and Eglot tells me otherwise: if robust simple Lisp snippets such as the one above are easy to find, users have no trouble applying them. But if we really must have a point-and-click interactive interface for programming-averse programmers :-) , then we can also remember that Eglot is also an Elisp-level API for major-modes to take advantage of. ... Which means that if the problem here is both LSP and Python-specific a .venv specific version of the above snippet could well live in python.el. Here, and in other cases such as complicated definitions of eglot-server-programs, or making use of server-specific LSP methods, there is no reason why a major-mode shouldn't (require 'eglot). Jo=C3=A3o