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 to core [Was: rmsbolt.el [Was: Colorful line numbers]] Date: Mon, 25 Jul 2022 18:05:25 +0100 Message-ID: References: <87leslpow2.fsf@gmail.com> <83ilnpl8e0.fsf@gnu.org> <874jz9peq0.fsf@gmail.com> <837d45l6ge.fsf@gnu.org> <87zgh1nyo6.fsf@gmail.com> <831qudl1k3.fsf@gnu.org> <87v8rpntiv.fsf@gmail.com> <83sfmtjjy8.fsf@gnu.org> <87fsitnpxd.fsf@gmail.com> <83k085jgxr.fsf@gnu.org> <87tu77vq1a.fsf@eve> <874jz6mj6b.fsf@gmail.com> <87r12aypas.fsf@yahoo.com> <87h735zp5o.fsf@yahoo.com> <87edy9i3aa.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c75e6805e4a42c6c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32785"; mail-complaints-to="usenet@ciao.gmane.io" To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Po Lu , Stefan Monnier , Stefan Kangas , Eli Zaretskii , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 25 19:05:53 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 1oG1Wi-0008OT-QI for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 19:05:52 +0200 Original-Received: from localhost ([::1]:48412 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oG1Wh-0005GT-G7 for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 13:05:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34398) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oG1VI-0003Xw-F1 for emacs-devel@gnu.org; Mon, 25 Jul 2022 13:04:24 -0400 Original-Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]:45644) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oG1VG-0003ji-Aa; Mon, 25 Jul 2022 13:04:24 -0400 Original-Received: by mail-ot1-x32d.google.com with SMTP id c20-20020a9d4814000000b0061cecd22af4so4625157otf.12; Mon, 25 Jul 2022 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ox1/NLYXgDdlYn3YwqcmGCqeRnwG0Q739xkUXAoi4Zs=; b=HQ4Yt+Tsj8Nqy2MKQCACAywwdZsBAN9vmRGJCnAP9ASVaqiEUY5hwd2Jg6D1SrG9hb 4nCeUEQccfA2rCszA8qlltiT+MGMQtINFC91tYx6ZZXyC11QorES/oY1hyhXIae4KdMo xy7Jns4/lKDg3mNnEtbiCqitUTPHlS/wjFy8sjKn8Z+ShNa9TUIpcCdV6Q5DQ1Q6R2cC n9aFgBDwJd70/60hjIxGn+Sclrs3aboX0suVL87tuaUKLT0eBg3lYQgdr3opGhFkiDaP o29YqYdUA6v+Rgu9i64pygmLmnUaCaFwY0hnTpgOkehZH5Hiz77QpTtSfR9gx3BZKv1G atQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ox1/NLYXgDdlYn3YwqcmGCqeRnwG0Q739xkUXAoi4Zs=; b=W7xu+JmGG5TS2yeYKNoSwJxTGswQWJgSolo8z6prX5YSwGthfmdMiiyllnqNyJnVZn cCh68QIR+fWy7bfO8cwh+5cY+SrFtlemzk3uiZAKy4EN/vo/zvqnC2yAUtqb1/Mx6AZl 1b0wA32ZOyZEim4QTzxER4UPATIIxgSDKoKXHazhlTpAamyC5QiI89gvBhkI3DtJLOpu 84vQT8iDlyy/KBRWAftvaCyv4+EqoetxnzfbsiA/C0z2/7zJI+mfStYg98K29cf+t684 h8Tzj19CdoVymIXEgXrbzkXTAjQQurgHWDquBYccT566aN47G2HseRw5BssR/lNc1CDe cknQ== X-Gm-Message-State: AJIora/BBjw+Wzs1THwUshpVJ2KR4nUtYenJdnsckMOqaLJgtbHvUHms b/7MW6NEq4bU+RUtVbKagnK4WKOhmTER1ksLYj0= X-Google-Smtp-Source: AGRyM1uub67Z1/j3QxN/RUuXPRVc4bKjfgJWc287cqovP8qCUuUNCtGECYzB0XrcC2AsI3UrIYpAboPadR5DzBHB/8w= X-Received: by 2002:a9d:7691:0:b0:61c:9963:7336 with SMTP id j17-20020a9d7691000000b0061c99637336mr5340371otl.317.1658768660584; Mon, 25 Jul 2022 10:04:20 -0700 (PDT) In-Reply-To: <87edy9i3aa.fsf@gmail.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::32d; envelope-from=joaotavora@gmail.com; helo=mail-ot1-x32d.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, 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-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" Xref: news.gmane.io gmane.emacs.devel:292643 Archived-At: --000000000000c75e6805e4a42c6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 25, 2022 at 5:08 PM Max Brieiev wrote: > Conceptually, Eglot matches a single major mode to a specific language server. That is true. > In some cases this is a limitation, because there are servers that are > supposed to handle the project as a whole. That is not the principal limitation, however. It could be in a specific case but it's not a fundamental one. The limitation is rather when multiple servers can operate on the same major mode of the same project, offering different perspectives on your source code. Like one language server dedicated to spelling, and the other to language things, one dedicated to a specific linter, etc... Often the language server itself aggregates these various perspectives For example the clangd server offers optional support for the clang-tidy linter, if it finds it. But this is not always so and I think that some LSP clients do allow multiple language servers to manage the same file. Eglot doesn't. It requires significant (but not impossible) work on the base model. I'm interested in hearing about a "killer use case" for this, i.e. in hearing about a case where a user has been forced to choose just one of twogreat language servers for a given major-mode. On a tangent: the language server jungle is vast and growing every day. The single greatest difficulty I have in understanding and addressing bug reports to Eglot is reproducibility. It always starts with someone working on language Foo using some special foo-mode.el and some special foo-server with some special configuration and asking me to debug a specific problem. Installing all these things (language toolchain, foo-mode and foo-server) on my machine is very time-consuming, not to mention debugging user's .emacs files. I just don't have the mental bandwidth. It would be great if someone could work on some "server-replayer" application that reads in Eglot event logs collected from actual servers or synthesized event logs, so that these installations aren't necessary. That would really speed up Eglot development and bug-hunting. > This is especially the case in web development. The project may contain > various content types: javascript, stylesheets, html, xml, json, > typescript, syntax extensions like jsx, and so on. > > This is where it is preferrable to have a single server instance per a > number of major modes. The server may read project configuration file > from the project's root directory, or be passed appropriate > initialization options during server startup. > > If major modes were to use Eglot's API in their own ways, wouldn't they > step on each other toes - e.g. each one passing conflicting > initialization options to the server? They surely could, but if there isn't some kind of consensus between the major modes, it's not too difficult to extract a horizontal *minor* mode that encompasses these differences. This is a common, effective Emacs way of solving this problem. Then have the minor mode set eglot-server-programs (or better yet, eglot-server-program) with the correct invocation. > Not sure whether Eglot supports this use case, but in the past I wasn't > able to get it working. It requires more coding, but it isn't extremely difficult. Have a look at the SLY Common Lisp IDE and the sly-mode minor mode in particular. It turns on in lisp-mode source files, and in special SLY buffers whose major mode isn't lisp-mode and whose content isn't necessarily Common Lisp source code. sly-mode sets and manages buffer-local variables that then work for all intents are purposes as you describe. The other difficulty you might face is that even doing the above with Eglot today will probably result in multiple inferior server processes being spawned (though now with the "correct" invocation). That may or may not be a problem and depends on whether the LS has a distributed architecture. If it doesn't, then Eglot also offers the TCP transport model, where one single server is first started and then each inferior process is actually a networking connection to that one process with a single address space. Jo=C3=A3o --000000000000c75e6805e4a42c6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 25, 2022 at 5:08 PM Max Brieiev <max.brieiev@gmail.com> wrote:

= > Conceptually, Eglot matches a single major mode to a specific language= server.

That is true.

> In some cases this is a limitatio= n, because there are servers that are
> supposed to handle the projec= t as a whole.

That is not the principal limitation, however.=C2=A0 I= t could be in a
specific case but it's not a fundamental one.=C2=A0 = The limitation is rather
when multiple servers can operate on the same m= ajor mode of the same
project, offering different perspectives on your s= ource code. Like one
language server dedicated to spelling, and the othe= r to language things,
one dedicated to a specific linter, etc...

= Often the language server itself aggregates these various perspectives
= For example the clangd server offers optional support for the clang-tidy linter, if it finds it.

But this is not always so and I think that= some LSP clients do allow
multiple language servers to manage the same = file.=C2=A0 Eglot doesn't.=C2=A0 It
requires significant (but not im= possible) work on the base model.=C2=A0 I'm
interested in hearing ab= out a "killer use case" for this, i.e. in
hearing about a case= where a user has been forced to choose just one of
twogreat language se= rvers for a given major-mode.

On a tangent: the language server jung= le is vast and growing every day.
The single greatest difficulty I have = in understanding and addressing
bug reports to Eglot is reproducibility.= =C2=A0 It always starts with someone
working on language Foo using some = special foo-mode.el and some special
foo-server with some special config= uration and asking me to debug a
specific problem.=C2=A0 Installing all = these things (language toolchain,
foo-mode and foo-server) on my machine= is very time-consuming, not to
mention debugging user's .emacs file= s.=C2=A0 I just don't have the mental
bandwidth.=C2=A0 It would be g= reat if someone could work on some
"server-replayer" applicati= on that reads in Eglot event logs collected
from actual servers or synth= esized event logs, so that these
installations aren't necessary.=C2= =A0 That would really speed up Eglot
development and bug-hunting.
> This is especially the case in web development. The project may conta= in
> various content types: javascript, stylesheets, html, xml, json,=
> typescript, syntax extensions like jsx, and so on.
>
>= This is where it is preferrable to have a single server instance per a
= > number of major modes. The server may read project configuration file<= br>> from the project's root directory, or be passed appropriate
= > initialization options during server startup.
>
> If major= modes were to use Eglot's API in their own ways, wouldn't they
= > step on each other toes - e.g. each one passing conflicting
> in= itialization options to the server?

They surely could, but if there = isn't some kind of consensus between the
major modes, it's not t= oo difficult to extract a horizontal *minor* mode
that encompasses these= differences.=C2=A0 This is a common, effective Emacs
way of solving thi= s problem.=C2=A0 Then have the minor mode set
eglot-server-programs (or = better yet, eglot-server-program) with the
correct invocation.

&g= t; Not sure whether Eglot supports this use case, but in the past I wasn= 9;t
> able to get it working.

It requires more coding, but it = isn't extremely difficult.=C2=A0 Have a look
at the SLY Common Lisp = IDE and the sly-mode minor mode in particular.
It turns on in lisp-mode = source files, and in special SLY buffers whose
major mode isn't lisp= -mode and whose content isn't necessarily Common Lisp
source code. = =C2=A0sly-mode sets and manages buffer-local variables that then
work fo= r all intents are purposes as you describe.

The other difficulty you= might face is that even doing the above with
Eglot today will probably = result in multiple inferior server processes
being spawned (though now w= ith the "correct" invocation).=C2=A0 That may or
may not be a = problem and depends on whether the LS has a distributed
architecture.=C2= =A0 If it doesn't, then Eglot also offers the TCP transport
model, w= here one single server is first started and then each inferior
process i= s actually a networking connection to that one process with a
single add= ress space.

Jo=C3=A3o
--000000000000c75e6805e4a42c6c--