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 16:41:52 +0100 Message-ID: <875yjlxkqn.fsf@gmail.com> References: <87leslpow2.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> <87r129h0nn.fsf@betli.tmit.bme.hu> <87ilnlxtqz.fsf@gmail.com> <87mtcxgrto.fsf@betli.tmit.bme.hu> 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="35480"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Po Lu , Stefan Monnier , Stefan Kangas , Eli Zaretskii , emacs-devel To: Felician Nemeth Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 25 17:41: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 1oG0D0-00095n-Oa for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 17:41:26 +0200 Original-Received: from localhost ([::1]:59454 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oG0Cz-00023o-Pv for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 11:41:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44040) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oG0CJ-00018q-4N for emacs-devel@gnu.org; Mon, 25 Jul 2022 11:40:43 -0400 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:40728) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oG0CH-0007Jw-6W; Mon, 25 Jul 2022 11:40:42 -0400 Original-Received: by mail-wr1-x436.google.com with SMTP id m17so16251990wrw.7; Mon, 25 Jul 2022 08:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=Sbreh6MqEZluH/sSvyqYborCkqnMFURUPwbNymJLkV0=; b=OC2axmwn/Mve7ctnKJ+aJdobHCE0jCjl2huEYdOthVx2+MTVHrkFfSgq+p2yuJU6ZF WauznorCDkmz3a1CaSw3ox8fGUpUVWdqQ8mjHBevBkFtxmHRPUnkbD7wEJlIQufF1SpP Z3RXy5MLV0IrziCGtOvqZ/CxLAMY13E9raP78TS/uCDrTzq+JhPnhRFhU5ImYHBCUb7k w2Gc8d9zCT3J/ggE9ieHJyelnd1oRCWKV9bkxZpMrJftuy290bilxDnbtOe9iX0qL3MX 4WA+21l+KK1JeDGDIZ+Wok6E89yZ8VR3mR3N+M7SPLXw6uTP+UDRBcHJ455hol7Dsabs kxpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version:content-transfer-encoding; bh=Sbreh6MqEZluH/sSvyqYborCkqnMFURUPwbNymJLkV0=; b=Xp688jbX49VFKrvEQpAjscQ98HLhO+gOAryoE2iBDQh70hB31RHEoobpDpmJqVO/UE SeaHCIdkSbkwBfj8kL7F/y3DQZLastBGG8Wkvj7TBFpTza5DF8KXHkLTYQBFF3XKm/FG yD9weQpSfMjCzjTyAkFIXEQzJZBmJMLwrzM+m2R8U+SRt/Gl1VE/F6nP0i8VZByJV0P9 v7PMWXYyU4fJLtP2/HPgpcVzJM0/5JtMmStg4/o52cbHXkJduGwtMxUJyH7ch/gWa5tk +ZQL6wtjKXTmnm9jsv0mqMY2/w9gg6nd89QgMsGk06O03DXN6DeQkMK8bip3/WRA7Y2J 613Q== X-Gm-Message-State: AJIora8msiXnCbUXOlvK7+PWRl+zNMQ8iBZev6kWvJf/Ul2D00TN75pi CAXdL9ulMUmtK3vQEapzwWUPfjPfOek= X-Google-Smtp-Source: AGRyM1s9SYIctEckFIZ57EMfhCy6oo2fIaMQqllnwTYIh8zsUTTBh1zjosqtYCwwBvwfYJ88LsnePg== X-Received: by 2002:a05:6000:1acf:b0:21d:b410:59b2 with SMTP id i15-20020a0560001acf00b0021db41059b2mr8397379wry.31.1658763639037; Mon, 25 Jul 2022 08:40:39 -0700 (PDT) Original-Received: from krug (87-196-74-31.net.novis.pt. [87.196.74.31]) by smtp.gmail.com with ESMTPSA id s2-20020a7bc382000000b003a3253b705dsm14750071wmj.35.2022.07.25.08.40.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Jul 2022 08:40:38 -0700 (PDT) In-Reply-To: <87mtcxgrto.fsf@betli.tmit.bme.hu> (Felician Nemeth's message of "Mon, 25 Jul 2022 17:00:51 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x436.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, 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:292638 Archived-At: Felician Nemeth writes: >>> I don't think the current API is good enough for that. See >>> https://github.com/joaotavora/eglot/discussions/802#discussioncomment-2= 171239 >> >> Really depends on what you consider "that" to be. > > To implement non-standard LSP features, which lots of servers propose. Yes, that's one of the possibilities. Another possibility is offering a different, perhaps richer interface to programming facilities specific to the major mode which may or may not rely on Eglot's LSP. For example, if LSP isn't available, or isn't the best choice for a particular feature (say completion, or definition-finding) this interface might delegate to some other tool, to CEDET, etc. >> [...] Also, once Eglot is in core, I won't be only person deciding. > > (I welcome Eglot's inclusion in the core and appreciate your work. I > hope that's clear.) And I hope it's clear that I immensely appreciate your work and your review efforts in Eglot. Eglot doesn't have many contributors who understand the code base well (and bringing it to core is also an effort to change that). >>> More importantly, there are multiple language server implementations for >>> some languages (python, c) with different quirks or non-standard >>> extensions to the LSP protocol. How do you imagine a major-mode would >>> support these? >> >> They can adds methods to the generic function eglot-handle-request (and >> a handful others), set values of Eglot in their major-mode >> initialization code, bind keys to `eglot-*` interactive commands, make >> compound commands from those commands, etc. > > OK. This is somewhat similar to the case when a major mode provides an > xref or a flymake backend. > > But I think sometimes the reverse approach is more desirable. Let's > take a not so hypothetical example and say c++-mode wants to provide a > type-hierarchy browser. It's better to write a generic, language > agnostic hierarchy browser (maybe CEDET even has one), and extend Eglot > with a hierarchy browser backend similarly to its xref backend. The > hierarchy browser then can have a tree-sitter backend as well. Yes, I fully agree. >> While they _can_, but that doesn't mean they _must_ or even _should_. >> In fact, LSP's whole idea, which is surprisingly forgotten so often, is >> that server and editor need to know very little about each other to be >> able to cooperate. By and large this idea works very very well.=20 > > I agree, but non-standard extensions exist for a reason. Yup, it's normal. You see the same in programming extensions that appear in specific compilers first. Some of then make it to the standards, some don't. Sometimes they make it in largely unchanged and adapting clients is easy, sometimes not so much. Standardization is hard. > Almost all servers have a VS-Code specific part that contains at least a > list of configuration variables that other clients cannot handle > automatically. BTW, if Eglot knew about these configuration variables, > could `customize-group` somehow save the settings into a .dir-locals.el > file? Very interesting. Yes, I think this is a great idea to allow the user to configure server-specific things easily and automatically save it .dir-locals.el. People tend to struggle with that, and it's=20 The question is how. Not sure if variables is the way to go. It _could_ be (but it could also be some plist/alist). But let's say it's variables, i.e. symbols holding values. Then these symbols belong to the major mode, not to server-agnostic eglot.el. Then maybe each such variable could have a symbol property 'eglot--server-specific-section' and 'eglot--server-specific-name'. Then there could indeed be a command M-x eglot-save-server-specific-variables that creates/updates .dir-locals.el for the given project. Maybe custom.el machinery could call that command automatically. But for which projects? All of them? The "current" one? We don't have project-specific custom.el And also when using variables I always think its nice not to force custom.el the user. I know others like me prefer to set things from .emacs. So it should work without it. >> Eglot works with tens of servers and hasn't got a line of server >> specific code, except for eglot-server-programs invocations. There >> are exceptions, and not everyone has the same luck, but I've been >> using C++ clangd and C# omnisharp quite a lot lately and I have 0 >> lines of server specific config. > > Even clangd has a moderately long list of extensions: > https://clangd.llvm.org/extensions.html#type-hierarchy > Sure, clangd is usable without them, but some of the extensions might > make someone's life easier, for example, by providing a type hierarchy > browser. Writing more C++ lately I do feel this need yes. I was looking at tree-widget.el the other day, but didn't make much progress. I fully agree to what you we should make some backend-agnostic frontend first and then plug it into eglot.el or eglot-x.el >> [...] So there isn't any problem/drama here. > I don't want to start one either, but it's a good time to think once > more about Eglot's relations with other packages. Aye, and that's always the thing with Eglot: it's at the intersection of many things. Jo=C3=A3o