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: Tue, 22 Nov 2022 21:40:47 +0000 Message-ID: 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> <87zgcml7g7.fsf@gmail.com> <2ba04533-097a-a1da-ff3f-2c9506fd488e@yandex.ru> <875yf9bbzb.fsf@gmail.com> <87wn7oa0aw.fsf@gmail.com> <7a5b76fd-fb15-8c1e-ea29-bf11f7e0d2ae@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000779f9605ee1602eb" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33957"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Danny Freeman , Eric Abrahamsen , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 22 22:41:24 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 1oxb19-0008iT-NV for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Nov 2022 22:41:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxazv-0002Wy-Hj; Tue, 22 Nov 2022 16:40:07 -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 1oxazr-0002Wl-IG for emacs-devel@gnu.org; Tue, 22 Nov 2022 16:40:03 -0500 Original-Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxazb-000644-1F for emacs-devel@gnu.org; Tue, 22 Nov 2022 16:40:03 -0500 Original-Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-1432a5f6468so509331fac.12 for ; Tue, 22 Nov 2022 13:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SHlp+MJ+U/1zULOWvd8OExNdOlRUdmb7nM019Ux80D8=; b=GlV7P2hvZF7r9Ao/nExVIaVz0UfuvqyDqBBrXaE8inU37FWqXDEncJHMz6scNcPTSM 1ABMbcler4zDJM98ef3wbOFh8PYQI83ui07QSbebcpAohl77FzdWgP39vHacJefsnApQ NUfs8NDoNtYxG34uVPOFH71EOrFfIOLVyd9h5fTXqgrbtdYmHq3Q3/MYk9lRjt6olGUh Q1qwPaXvA0i1uKvxo6zwXvWJK+dqDm+JDhwekVKvF4BnPk4jTT9PVCffgdqFL4UGs8Z2 xALokNJmdQpYTrulJ6UdHb1L+8YIzDvpqow+hLkguOgHxbPY4CsqADyf/hLZJVzoI9eR YgJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SHlp+MJ+U/1zULOWvd8OExNdOlRUdmb7nM019Ux80D8=; b=gQm5XSpurjwnKYlSM3yPxyd4m6fwiXQtmYZRs/MmTmqjSd/7CHKSqf5JDh832OuzP7 oD7U+Az4CtaETX+OkJ/86f397GQ3+vNEoLUjoYMPFhNp2jYR22MSKkVDG7uqVjPYeP8k xqTaKEQLXJR7+1qJvt/llglMfcp5BkeklN3VgZY/kSZ2Ef0izIPKpoxkmDtp5KkYPcmr rfRcUR/PgfsL1K2q31aU/In7LSBLUDjkZcojfyTnmjNjeFaub3BnjDLU5WkVFuimkK1D MUiWHcDmaEnf4EXUvJQahPPV9WKHzJKze7M+DAJrbphbaubQ2rMvhuaDHo5K7eZ5iFae viIw== X-Gm-Message-State: ANoB5pnQ+NsKZ0fHhdjeS/QzJ9TOIKLPgXp8BbO4GL4hi/JXQ+U7RC5t rkK7GpzW6a+1AFzGtTYAqmgVSL555DKc3sZsYLs= X-Google-Smtp-Source: AA0mqf6GaENTP0Qw23uAcBgEqu6dh1sRjByBqV6WW31xqwQeQSfoygv6uJdVB5ggUHmKrhU29GQAC4i+m4pxKgUK1Rk= X-Received: by 2002:a05:6871:4590:b0:132:a103:ae22 with SMTP id nl16-20020a056871459000b00132a103ae22mr14314069oab.215.1669153181636; Tue, 22 Nov 2022 13:39:41 -0800 (PST) In-Reply-To: <7a5b76fd-fb15-8c1e-ea29-bf11f7e0d2ae@yandex.ru> Received-SPF: pass client-ip=2001:4860:4864:20::2b; envelope-from=joaotavora@gmail.com; helo=mail-oa1-x2b.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 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:300358 Archived-At: --000000000000779f9605ee1602eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 22, 2022, 15:48 Dmitry Gutov wrote: I cannot reasonably add a feature with only one known (and expected) > consumer. Whether we call it subprojects, or an eglot-only backend, or et= c. > I've given you two other cases of non-Eglot consumption. In fact, my problem isn't really Eglot/LSP-motivated at all: AFAICT clangd.exe works fine with that monster repo. Rather it's the fact that the monorepo is clearly organized into loosely coupled sub-projects and very often (but not always) it makes sense to do sub-project wide file-finding and reference-finding. No LSP/Eglotness involved at all. As I explained earlier, it would also help if project-files weren't so "flat list" oriented and allowed generalized collections, such as my completion table based on a very fast external indexer. > As the Eglot "fix" for the current status quo, it's just a > > documentation change to the manual. > > I think it's a problem when a significant part of userbase need to make > a change to their config (a specific, non-trivial one) to make Eglot > functional in their projects. > Depends what you call significant, and non-trivial. Eglot aims to make the common stuff trivial, and the complex stuff possible. 80-20 rule. Of course, as soon as you discover that a certain usage pattern is falling to the "80" side of things, you make it easier for that case. If that case is Python "venvs", and those are indeed very common, then make Python mode use Eglot's and project.el's API: it's what they are there for, I would presume. I sympathize with not wanting to collect that info for every file type > and their dog in Eglot, but it's not 100% obvious to me that the place > for that info is in major modes. > "File types" are handled by the major mode abstraction in Emacs. Eglot strives not to change that and I think this is a winning idea. Jo=C3=A3o > --000000000000779f9605ee1602eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 22, 2022, 15:48 Dmitry Gutov <= dg= utov@yandex.ru> wrote:
I cannot reasonably add a feature with only one known (and expected)
consumer. Whether we call it subprojects, or an eglot-only backend, or etc.=

I've give= n you two other cases of non-Eglot consumption.=C2=A0 In fact, my
problem isn't really Eglot/LSP-motivated at all: AFAICT clangd.ex= e works
fine with that monster repo.

Rather it's the fact that the monorepo is clearly organized into loos= ely coupled
sub-projects and very often (but not always) it makes= sense to do sub-project
wide file-finding and reference-fin= ding.=C2=A0 No LSP/Eglotness involved at all.

As I= explained earlier, it would also help if project-files weren't so &quo= t;flat list"
oriented and allowed generalized collections, s= uch as my completion table
based on a very fast external indexer.=

> As the Eglot "fix" for the current status quo, it's just= a
> documentation change to the manual.

I think it's a problem when a significant part of userbase need to make=
a change to their config (a specific, non-trivial one) to make Eglot
functional in their projects.

Depends what you call significant, and non-tri= vial. Eglot aims to
make the common stuff trivi= al, and the complex stuff possible.
80-20 rule.=

Of course, as soon as you discover that a= certain usage pattern
is fal= ling to the "80" side of things, you make it easier for that case= . If that
case is Python "venvs", and= those are indeed very common, then make
Python= mode use Eglot's and project.el's API: it's what they are ther= e
=C2=A0for, I would presume.

I sympathize with not wanting to collect that info for every file type
and their dog in Eglot, but it's not 100% obvious to me that the place =
for that info is in major modes.

"File types" are handled by the m= ajor mode abstraction in Emacs.=C2=A0
Eglot str= ives not to change that and I think this is a winning idea.

Jo=C3=A3o
--000000000000779f9605ee1602eb--