Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 14:53:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 10:53:47 2026 Received: from localhost ([127.0.0.1]:45187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3xhz-0008MR-1p for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 10:53:47 -0400 Received: from mout01.posteo.de ([185.67.36.65]:35359) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1w3xhu-0008Ko-HN for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 10:53:44 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 31D2C240027 for <80595 <at> debbugs.gnu.org>; Sat, 21 Mar 2026 15:53:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1774104816; bh=NdiBbz8Og77BP3iQIq0ujTp9tiLtZ4nu68dxiTCKHHs=; h=Date:From:To:CC:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=AU6Q2Oral7SHVjRd40P5VvNgpQ8kopiIFxlexDINPW+YGhX/vxHaqriYnoOQth3rG ARi8CYBQZIPgneY5mGUhNw4buvSytprzaaw+22sLA56JHj9YeQMrNKtm/02npkfuVg r1N5amOEqjB9cU5zHDw//oRAupsSvoHTXyyhETpjExd+YPtV8rVS6qWHgamDX5FGPJ A+3Up4qDtqRXxDLX7hhKcY3/H2zx2PldEn/Sxrz1JORUW49BQmmViGGi+AfZDl/Z8v pX7TNVXbl/nJa8xfm1gp0gQX+l1hPVAM1ZESgyPF/pdcAvnsiX1V7aKL9kkkN6la+3 z9Bvuvf5uaCIg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fdMrH59Wqz9rxF; Sat, 21 Mar 2026 15:53:35 +0100 (CET) Date: Sat, 21 Mar 2026 14:53:36 +0000 From: Philip Kaludercic <philipk@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2380595=3A_=5BPATCH=5D_Prepare_infrastru?= =?US-ASCII?Q?cture_to_move_LSP_servers_out_of_eglot=2Eel?= In-Reply-To: <86ikap9rby.fsf@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN> <874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN> <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> <864im9d0ja.fsf@HIDDEN> <077D696D-ED11-4523-86B6-90EC083D067F@HIDDEN> <861phdcxt6.fsf@HIDDEN> <230A7409-2283-4DF8-B198-3467E623FEE8@HIDDEN> <86ikap9rby.fsf@HIDDEN> Message-ID: <98F9F14D-A074-430B-BAE0-1043B17400BD@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 21 March 2026 15:42:41 CET, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> Date: Sat, 21 Mar 2026 14:25:23 +0000 >> From: Philip Kaludercic <philipk@posteo=2Enet> >> CC: joaotavora@gmail=2Ecom, 80595@debbugs=2Egnu=2Eorg >>=20 >> >I thought you _wanted_ to decentralize it, so that in some distant >> >future each major mode could be responsible for its setup of LPS >> >servers=2E >>=20 >> I think it would make sense to decentralize the declarations (ie=2E the= locations in files), but that doesn't mean the value has to also be decent= ralized=2E Ideally, I'd hope we could have a similar setup to auto-mode-li= st=2E > >That's not possible, at least not easily, because, unlike >auto-mode-list, eglot-server-programs is not defined until eglot=2Eel is >loaded=2E But we could work around that by autoloading the declaration that sets the= variable to nil=2E >But I don't see that as a significant downside, because looping over >all the buffers and collecting the values of this new variable >shouldn't be much harder than looping over the elements in >auto-mode-list=2E That would only work for buffers that are currently open, which is also no= t bad, but not as complete as with a global variable=2E >> >If the problem is to have a command that checks if a major mode >> >supports LSP, we could solve it in some way=2E But that's a separate >> >problem, so we shouldn't reject clean solutions of this one on behalf >> >of the other one=2E >>=20 >> I'm just trying to look ahead, and think that having a centralized vari= able that is decentrally declared would be useful=2E >>=20 >> >> A compromise solution could be to use symbol properties on the major= mode name, because they are easier to look up than buffer local variables,= while avoiding the complication of modifying a global variable that might = not be loaded yet=2E >> > >> >Yes, or something else=2E It's a separate problem=2E Let's solve one >> >problem at a time=2E >>=20 >> I think this is an alternative solution to the same problem? > >What is? The problem is how to distribute the locations where Eglot is informed abo= ut how to start a LSP server, right? The options we have come up to this problem are: 1=2E Extend a global vari= able=2E 2=2E Set a buffer local variable 3=2E Set a symbol in the symbol pl= ist (of the major mode)=2E
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 14:43:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 10:43:12 2026 Received: from localhost ([127.0.0.1]:45061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3xXi-0004VG-ME for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 10:43:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45958) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w3xXd-0004Th-DZ for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 10:43:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1w3xXY-0000JO-13; Sat, 21 Mar 2026 10:43:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=O81B3EzKT0cGUjspcF8fNGfO2Shx5WBvzFWuqzty+4I=; b=EdYAVcI4r2Vi cYNYVK83N/Q4gLhtOrukNDcTE3eYA8QwIO3In7efIkRXbGxMohzeVhPnJDB2CxxmU0oCO04zplJ+i Mf/GCpnfszd8DQgX9CZ9UleUlYCgzC4kYM8P/O0V1g6FdyW/VE2moQu8GcB+xEKjBUbxrqyn+NVny MN2fGm6MYL/CnrEIlfCB/aOYOLrtmzA4iJdbwVP9sM7y7hF6tL4EW/h21EBxxvPzjko1rz9eAkqfH DLITApbv+2G7Lf+0AygopDMwfku7Jpi65zF5UJUoPmaYOkt87OWHeOuBk7ZYkhCY4X6T93PbWinMo D1AXGEJMtifb779qjhd+Rg==; Date: Sat, 21 Mar 2026 16:42:41 +0200 Message-Id: <86ikap9rby.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> In-Reply-To: <230A7409-2283-4DF8-B198-3467E623FEE8@HIDDEN> (message from Philip Kaludercic on Sat, 21 Mar 2026 14:25:23 +0000) Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN> <874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN> <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> <864im9d0ja.fsf@HIDDEN> <077D696D-ED11-4523-86B6-90EC083D067F@HIDDEN> <861phdcxt6.fsf@HIDDEN> <230A7409-2283-4DF8-B198-3467E623FEE8@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 21 Mar 2026 14:25:23 +0000 > From: Philip Kaludercic <philipk@HIDDEN> > CC: joaotavora@HIDDEN, 80595 <at> debbugs.gnu.org > > >I thought you _wanted_ to decentralize it, so that in some distant > >future each major mode could be responsible for its setup of LPS > >servers. > > I think it would make sense to decentralize the declarations (ie. the locations in files), but that doesn't mean the value has to also be decentralized. Ideally, I'd hope we could have a similar setup to auto-mode-list. That's not possible, at least not easily, because, unlike auto-mode-list, eglot-server-programs is not defined until eglot.el is loaded. But I don't see that as a significant downside, because looping over all the buffers and collecting the values of this new variable shouldn't be much harder than looping over the elements in auto-mode-list. > >If the problem is to have a command that checks if a major mode > >supports LSP, we could solve it in some way. But that's a separate > >problem, so we shouldn't reject clean solutions of this one on behalf > >of the other one. > > I'm just trying to look ahead, and think that having a centralized variable that is decentrally declared would be useful. > > >> A compromise solution could be to use symbol properties on the major mode name, because they are easier to look up than buffer local variables, while avoiding the complication of modifying a global variable that might not be loaded yet. > > > >Yes, or something else. It's a separate problem. Let's solve one > >problem at a time. > > I think this is an alternative solution to the same problem? What is?
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 14:25:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 10:25:35 2026 Received: from localhost ([127.0.0.1]:44875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3xGf-0002mK-Gm for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 10:25:35 -0400 Received: from mout02.posteo.de ([185.67.36.66]:38247) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1w3xGc-0002lN-Dg for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 10:25:31 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BC63E240101 for <80595 <at> debbugs.gnu.org>; Sat, 21 Mar 2026 15:25:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1774103123; bh=lwb+t7KfX1nSdlWEb3MvjxiRXaqO4xHQX2FLITpAnLE=; h=Date:From:To:CC:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=UpUvPUOzV0CfOqwicken9ug5FQw0UXwIpB6LbvquQC7Fgu6Zh0LC4Z+abOri/nc8Q dZhyAmbNAMjeFbfQjfmi6nnLpEY+FZRM/tdr0/ISCjcJKT7IY1h0owk/4WtzvgtJSN g1NEeu0J38kiug/EAvkKJexyAjZaanbzPXESb/y4a4UZTe/l+WPaQXTV8lfPRbmYKh vW4bL95K5YNKHvpYElD/+zJcXpnpJgVj/RkzwxSYNgtCn+lEe/5Ta07KKuN9x/2bNT 3EH1uePAh7OWSWyAyi+7MEd4L6jZct7PYsGxjxEVmYKDWDdGCW7sREPrAsJSbTJDcU YbruG2Sm/k9Kw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fdMCk6pYXz6twj; Sat, 21 Mar 2026 15:25:22 +0100 (CET) Date: Sat, 21 Mar 2026 14:25:23 +0000 From: Philip Kaludercic <philipk@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2380595=3A_=5BPATCH=5D_Prepare_infrastru?= =?US-ASCII?Q?cture_to_move_LSP_servers_out_of_eglot=2Eel?= In-Reply-To: <861phdcxt6.fsf@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN> <874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN> <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> <864im9d0ja.fsf@HIDDEN> <077D696D-ED11-4523-86B6-90EC083D067F@HIDDEN> <861phdcxt6.fsf@HIDDEN> Message-ID: <230A7409-2283-4DF8-B198-3467E623FEE8@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 21 March 2026 10:54:29 CET, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> Date: Sat, 21 Mar 2026 09:24:25 +0000 >> From: Philip Kaludercic <philipk@posteo=2Enet> >> CC: joaotavora@gmail=2Ecom, 80595@debbugs=2Egnu=2Eorg >>=20 >> That was an option as well, the main disadvantage is that we loose a ce= ntralised database, that we might use for a command that could check what m= ajor modes have LSP support=2E > >I thought you _wanted_ to decentralize it, so that in some distant >future each major mode could be responsible for its setup of LPS >servers=2E I think it would make sense to decentralize the declarations (ie=2E the lo= cations in files), but that doesn't mean the value has to also be decentral= ized=2E Ideally, I'd hope we could have a similar setup to auto-mode-list= =2E >If the problem is to have a command that checks if a major mode >supports LSP, we could solve it in some way=2E But that's a separate >problem, so we shouldn't reject clean solutions of this one on behalf >of the other one=2E I'm just trying to look ahead, and think that having a centralized variabl= e that is decentrally declared would be useful=2E >> A compromise solution could be to use symbol properties on the major mo= de name, because they are easier to look up than buffer local variables, wh= ile avoiding the complication of modifying a global variable that might not= be loaded yet=2E > >Yes, or something else=2E It's a separate problem=2E Let's solve one >problem at a time=2E I think this is an alternative solution to the same problem?
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 13:43:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 09:43:02 2026 Received: from localhost ([127.0.0.1]:43047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3wbW-0005tt-CJ for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 09:43:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59476) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w3wbT-0005su-Rr for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 09:43:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1w3wbO-00071S-9P; Sat, 21 Mar 2026 09:42:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=uq994cc3TWdatdYI9emneW/sM2QVEqDXhQSLreCL/Hk=; b=LrzCpEdSUEgFDM7kFppI lbSjVPQtllwg6/hHQ4pDXTBzLmNnSgrwwY3fALVP1dMxWvZX3kaIfFy3atZLiczU8KGuqd9cK10Ti RcHkRl8WCjwg54RumKYvPbz4RGITAVbNWrpbtRZCzwvN4CZBV/b2F5lbNPqxReQS5ht81Bv6zShGC SRUh9+Tg8pptx/PWHhKzVG8nJeJNCX5mZVczuL19sUAiaoAivSOliGuCIWU/R/eu0KPhNVaowiW3i R9QucGnJ9IEMP5l8YLEKjFjw8gjl97wcV3jLrSUy3CASnLjWzQdedSVDLx1C2bt5nW2SLEN8t8YWW B490jIuVKe0Myg==; Date: Sat, 21 Mar 2026 15:42:02 +0200 Message-Id: <86se9t9u51.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <CALDnm52UL-KSC4ZT2xBzRBgm-gH13qjKDrHx4N+D3w2KD_-BxQ@HIDDEN> (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 21 Mar 2026 12:47:55 +0000) Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN> <874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN> <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> <864im9d0ja.fsf@HIDDEN> <CALDnm53JjmEbZw5xPjjs5=zT1j9v6-9h6OiPGH6HOnyoirQqBg@HIDDEN> <86zf41bj44.fsf@HIDDEN> <CALDnm52UL-KSC4ZT2xBzRBgm-gH13qjKDrHx4N+D3w2KD_-BxQ@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org, philipk@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Sat, 21 Mar 2026 12:47:55 +0000 > > > If we want to stop using the central database in eglot.el, we should > > tell such contributors to redo their patch so that the corresponding > > major mode sets that new variable. We could also decide to install > > both changes, at least in the interim period. It's up to us, and I > > think bo0th ways will work. > > Good. A possible policy decision, at last. After this interim period, > you realize users of GNU(-devel) ELPA Eglot will lose access to this > new server (or altered server invocation) out-of-the box, right? Why would they lose it? I think you are assuming something that you didn't explicitly say. Perhaps what will we do after the interim period ends? If the change is done both in eglot.el and in the major mode, then I don't see how users will lose anything. Even if we decide to delete eglot-server-programs (or make it nil), then the local variable set by the mode will allow Eglot start the server. What am I missing?
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 12:48:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 08:48:02 2026 Received: from localhost ([127.0.0.1]:42407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3vkI-0001yf-9i for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 08:48:02 -0400 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:47546) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w3vkG-0001y8-1t for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 08:48:00 -0400 Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-7d7422b4ff1so961968a34.3 for <80595 <at> debbugs.gnu.org>; Sat, 21 Mar 2026 05:48:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774097279; cv=none; d=google.com; s=arc-20240605; b=PJVA5dIYFiXbVIxUAYIhTWltP9bHitpPvJky1CREPcY9NMdBFLNQMNGN2tNQgEDRlJ HhM86e0pmLh1xyMf33Qo+djc06APkkaIfJayycs/tHoGkd477YslmntBcnd7jpkqvoPt vziZFTzdCUGTBhLx3ag/H3hTijO02Lg0PvUFLnRSdu01EcoppZiRIbC/g7IEUxQMlTMD qcvlqul3ZVj4sV8+7qlub/0QqBX2hN72eVrrbrsGlC2fJg3/ZsJFAjHeDxNngP78mloF 2yzvcMOYLUnTi1iUdm3wofi8gBsP3ONlK04SzmkF4TEwwtGs8KTR02mOKVdOD4uOhSp4 2CHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=z++w+piMi0A+uxpiKOGP1drBaBn6lVHQY9qhnHlssGA=; fh=+AquSMWvWzVrYNlS/K5GbrA5TlQ1Pk8ElyvnR6dHk54=; b=NZhcR4WHIiOdlQpSI54lq3xqCoElWpMk5/aGZsc4eucLPh9eLyUaUqNycPdtdA3jt9 L29PPzXhI+2vra+GUqsQyJVuVP2O39yybjxIJzjf63D+oAyb6txWbRkaj/eGsha7BWe0 OUiurwUe0dDR2vZ8oGxd7QmjQ/ruIEgBwv0vGso0N2W+BXJQTVTXzjG62MfKcF1CO6UB YtkYhiztvv5tqZzwkDT2hZv1zKp3f65CNweH1bZy/vjuk4yQNBX7CkE1LZRQ/m4rHKlt hGbvvWCMdjf+2B/tSCW88teRHh3ROjKzzILcMTte6lzK2HhRRa7FwQVnYL4YXdOzslbE VD7A==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774097279; x=1774702079; darn=debbugs.gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=z++w+piMi0A+uxpiKOGP1drBaBn6lVHQY9qhnHlssGA=; b=UX+yViTVX6y+y2P1nat8HHERVturFSHcyxBv/jSmlen6LIYxrDMYyBuigA0DeXJpcy JLYRZXJlpoL+uaJ9l4c0U2r7D1MdmkUoN5iR5RvZqqti+fclw6Ak0h6Efie1MZl5gufb gPkGdL6VcVB/nX6CF+j956q7yFVwN1WKv+J0MHHuu1MLAfOVEUhVDJFRd5zDWSZ2Ngq/ ml+pAOXEZAepvNh+C0Kv+vgGOuIeJo6wICsobkggOisn654u+NJ+Yvi4RF22C9iCu5Si iYZtV7vBSiFtAd/Fmp1WnMaJpTiH09oUz1B7uTxzGHWbyEGbIhHJx6pYd3dy0naoJgmz JAoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774097279; x=1774702079; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=z++w+piMi0A+uxpiKOGP1drBaBn6lVHQY9qhnHlssGA=; b=DroRoZhrA0moLBnKHBR08RbOeLqPbgAJZJkg1UepXFdMcrgQbe5a55AsN4T4k5Zoa0 YSX7bGtwXh7F/lO/mTmsaOEzwxHxqxQdCLVzMn77gCy49HREX5+TkHVmmxMFWwKieWKC OUJBrk+PNqFucc0SoH+zjVUBU7MSHt0iInRDIHsonCCNzyZ58iBPcpaIc7pLj5gc9x+e gSkxiresqzJaFsJroXXIrjhetUB5u/WOPF1c+6pNgxhF5mnNzfOHT5sizLNsaxdFbuiq EIZqBNOPil1ugdStNfQqojKNOYkkIgZu8PfA1cUTOup1bptQcMNu/XwFyUIIZgeYKpRd 3urg== X-Forwarded-Encrypted: i=1; AJvYcCXcrlWa7MwZG2l3KqhLiQ72gvMT9BZGuRY1jduPuArXfa0Rup5NHE9QhK26XOgEDFAyeSeFUg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwE8AWy51mzR21LP/r2vCNumTc1NPue2CnRGK63Z6kbZJynfIkc 5LE9mLeUOLumHmPfOIDUw1uuC6JB+uG7Aazd3JNTHCVQ5oGpYeHuoXRMxzcw0HDltNlwMTSPRby nCazctKkNmn2l4/TC3Slgqb6wzaToYKY= X-Gm-Gg: ATEYQzynofr3vQGRM8a09u9cSAUpz9IIfWCr38HSBvlwqjCXY5lKtzhQsSQ6ZaSv6aW ZaycdVuclBgcpSqJFvgENRDBjzQAPbQj7HkS2XA2p2uLN8AtkxweKYs9UKPgRVDRGCHS9jgynXU IbeTmRzcc9LZHY9jMHxaQWCm+2xzei7PJUJE4DlUqavF7HFmToNAGv3p1YEk0ipx6oNvBKinsSK FbsGQn2Ls0faB/i64P/zjL7J7086rbyKIzLE/OEUmgtSgV8Tp6Y+YwsCooFdTt460LLOvM8KFJJ 3+PzeHG5XIz7pOFIOsxThX/wj6a8uMUQ/CWRvA88FnjcUczMtrfBrPvZXVMNKclmxfg= X-Received: by 2002:a05:6830:6d2a:b0:7d7:da02:1aa4 with SMTP id 46e09a7af769-7d7eae3f3e3mr3847002a34.1.1774097279096; Sat, 21 Mar 2026 05:47:59 -0700 (PDT) MIME-Version: 1.0 References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN> <874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN> <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> <864im9d0ja.fsf@HIDDEN> <CALDnm53JjmEbZw5xPjjs5=zT1j9v6-9h6OiPGH6HOnyoirQqBg@HIDDEN> <86zf41bj44.fsf@HIDDEN> In-Reply-To: <86zf41bj44.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Sat, 21 Mar 2026 12:47:55 +0000 X-Gm-Features: AaiRm50TlCZmIpRBvHs1PX51daYSgsXsEqYpptvWHh8he3Dbv_pswXCgLGqdGO8 Message-ID: <CALDnm52UL-KSC4ZT2xBzRBgm-gH13qjKDrHx4N+D3w2KD_-BxQ@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el To: Eli Zaretskii <eliz@HIDDEN>, 80595 <at> debbugs.gnu.org, "Philip K." <philipk@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80595 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) [> P.S. Did you intentionally replied only to me? No it was unintentional. Rejoining the thread here. ] On Sat, Mar 21, 2026 at 9:57=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote: > > I think this will allow the major modes which want to specify the > > servers without any conflicts with eglot-server-programs. Or am I > > missing something? > > > > This could work, as could other things. But the question is what to do = for contributors who submit a new server > > X for foo-mode, after we do this switch. Do you put it on eglot.el, foo= -mode.el, both? > > If we want to stop using the central database in eglot.el, we should > tell such contributors to redo their patch so that the corresponding > major mode sets that new variable. We could also decide to install > both changes, at least in the interim period. It's up to us, and I > think bo0th ways will work. Good. A possible policy decision, at last. After this interim period, you realize users of GNU(-devel) ELPA Eglot will lose access to this new server (or altered server invocation) out-of-the box, right? I think that's a perfectly worthwhile loss, since it's easy to configure them by hand usually. But it's a loss, and it's important to be aware of that. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 09:54:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 05:54:39 2026 Received: from localhost ([127.0.0.1]:40667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3t2V-0007W8-6t for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 05:54:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43652) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w3t2S-0007VV-LY for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 05:54:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1w3t2M-0001Y4-PL; Sat, 21 Mar 2026 05:54:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4NEoFpJi1R0FPJiHW9W0RkOZVn7+GYKey9RtlEn8q2g=; b=fcU7gq44Mvzi 2u66WYv6Fr0WgIGOn+WXDuHAGH6M8/aKpunY3EVgk1GZhQptqcW0FolZJ5x62j8z8S+BfJ4p9MMwi KLEzTWFZlhBioTnqyQWkHQM/BtFdyvrPigLvMTKMJNQDLPIv/xXtF7pLO7o5b7vfLqumdw5pw9787 snkQsxlYcoQGel9pxt+VirNwXzn4FwATz33fKLTvSkcINlFkqfS4cE2xdIAaIDTMliGcB2gtt7p4X hbh2WQEF7DTzDOnLyNN+24spIw0OuAizYWfmDIkYryDIkqBhDOEfB4pHqlQZuUlo0/rjJ8MVuFgqd djKGB+D/a06XJeUdZZXk5w==; Date: Sat, 21 Mar 2026 11:54:29 +0200 Message-Id: <861phdcxt6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> In-Reply-To: <077D696D-ED11-4523-86B6-90EC083D067F@HIDDEN> (message from Philip Kaludercic on Sat, 21 Mar 2026 09:24:25 +0000) Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN> <874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN> <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> <864im9d0ja.fsf@HIDDEN> <077D696D-ED11-4523-86B6-90EC083D067F@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 21 Mar 2026 09:24:25 +0000 > From: Philip Kaludercic <philipk@HIDDEN> > CC: joaotavora@HIDDEN, 80595 <at> debbugs.gnu.org > > That was an option as well, the main disadvantage is that we loose a centralised database, that we might use for a command that could check what major modes have LSP support. I thought you _wanted_ to decentralize it, so that in some distant future each major mode could be responsible for its setup of LPS servers. If the problem is to have a command that checks if a major mode supports LSP, we could solve it in some way. But that's a separate problem, so we shouldn't reject clean solutions of this one on behalf of the other one. > A compromise solution could be to use symbol properties on the major mode name, because they are easier to look up than buffer local variables, while avoiding the complication of modifying a global variable that might not be loaded yet. Yes, or something else. It's a separate problem. Let's solve one problem at a time.
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 09:24:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 05:24:36 2026 Received: from localhost ([127.0.0.1]:40360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3sZP-0004RL-IL for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 05:24:36 -0400 Received: from mout02.posteo.de ([185.67.36.66]:49859) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1w3sZM-0004Qk-B4 for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 05:24:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 0C941240101 for <80595 <at> debbugs.gnu.org>; Sat, 21 Mar 2026 10:24:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1774085066; bh=mdjM6DRa9k7+1k8BOAD/HcBaShKMo7GjX9GvkGZlZBI=; h=Date:From:To:CC:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=HrwSW7DqJqjx7ii/E9ug9HjX+MlE3w/VeiaxhmOFJsTR/MbLB4+6NvAO1xE1FXomU Ig/MfxeYVUrO8FOfhePI7IMqCYq1+5x9YHMIgtQIwC4O0HTeE7qZwP+Yn8SHaQZN9m NkNbEQwEfwhD56zOrTN5DlgkZs+28DFWBLAmPgOpIoa7PRZ0PsKVpUk6FjCpLOKkvP YrV+VDyy4A09sW1NXzpfO9WBgZJh8NAA1p/K4chBWuYfbqauIEiRBUJmktgOz1KIfW oZAq7eheZy11lkzaTukSh7Iq7I6GoM57ritmbHMBzUoN7zu/6QsxT/G4Xbc3G4baXp VEm4yG/BDUsJw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fdDXT09PVz6twG; Sat, 21 Mar 2026 10:24:24 +0100 (CET) Date: Sat, 21 Mar 2026 09:24:25 +0000 From: Philip Kaludercic <philipk@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2380595=3A_=5BPATCH=5D_Prepare_infrastru?= =?US-ASCII?Q?cture_to_move_LSP_servers_out_of_eglot=2Eel?= In-Reply-To: <864im9d0ja.fsf@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN> <874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN> <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> <864im9d0ja.fsf@HIDDEN> Message-ID: <077D696D-ED11-4523-86B6-90EC083D067F@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) That was an option as well, the main disadvantage is that we loose a centra= lised database, that we might use for a command that could check what major= modes have LSP support=2E A compromise solution could be to use symbol properties on the major mode = name, because they are easier to look up than buffer local variables, while= avoiding the complication of modifying a global variable that might not be= loaded yet=2E On 21 March 2026 09:55:37 CET, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> Cc: 80595@debbugs=2Egnu=2Eorg >> Date: Sat, 21 Mar 2026 08:25:38 +0000 >> From: Philip Kaludercic <philipk@posteo=2Enet> >>=20 >>=20 >>=20 >> On 20 March 2026 15:24:35 CET, "Jo=C3=A3o T=C3=A1vora" <joaotavora@gmai= l=2Ecom> wrote: >> >Philip Kaludercic <philipk@posteo=2Enet> writes: >> > >> >> Jo=C3=A3o T=C3=A1vora <joaotavora@gmail=2Ecom> writes: >> >> >> >>> Philip Kaludercic <philipk@posteo=2Enet> writes: >> >>> >> >>>> The first step is to adjust Eglot in such a way that major modes c= an >> >>>> indicate what LSP servers should be used=2E This doesn't mean rem= oving >> >>>> any current features from Eglot, just adding something new=2E We = can use >> >>>> the existing variable or come up with a new one, but that is it=2E >> >>> >> >>> You don't need any adjustment: if you don't want a e-s-program sing= ular >> >>> variable (and maybe that's not a bad idea) just have the major-mode= set >> >>> the e-s-programs plural variable buffer-locally=2E In fact I think= at >> >>> least one major-mode already does this, or I suggested that it coul= d do >> >>> it=2E I don't see any big problems with it=2E >> >> >> >> The complication here is that the major mode has to take into accoun= t if >> >> eglot has already been loaded or not=2E Not the end of the world, b= ut an >> >> unnecessary complication=2E >> > >> >Sounds way less complicated to (require 'eglot) then to add a new vari= able >> >to eglot=2Eel that has to follow precedence rules, etc=2E >>=20 >> We can do that, but then everyone has to load eglot even if it is not n= ecessary, which is what I was trying to avoid=2E >>=20 >> >> Also, if the variable is buffer-local then we loose the ability to >> >> have a global lookup table of supported major modes and their server= s >> > >> >Why? Why can't the mode use (default-value 'eglot-server-programs) to >> >get to the global database? Then again you say you want to set that >> >global value it to nil eventually, so again, your plan seems a total >> >mistery=2E >>=20 >> No, I am suggesting to set the _default_ value to nil, so that you can = populate it using global `add-to-list` calls=2E > >Forgive me for suggesting something you've perhaps already considered >and rejected for some reason, but how about the following alternative: > > =2E we add a buffer-local variable whose value gives the LSP server(s) > for the current buffer > =2E major modes could set this variable to name the LSP servers they > support > =2E Eglot will check this variable, and if non-nil, will use its value > in preference to what's in eglot-server-programs > >I think this will allow the major modes which want to specify the >servers without any conflicts with eglot-server-programs=2E Or am I >missing something?
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.
Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 08:55:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 04:55:54 2026
Received: from localhost ([127.0.0.1]:40096 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w3s7e-0002Dj-08
for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 04:55:54 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:44938)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w3s7b-0002DA-Rm
for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 04:55:52 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1w3s7W-0000wn-Dj; Sat, 21 Mar 2026 04:55:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=jvB1NUVkG7BQnipf47FsewUlTSVJavx6qZ7/GVl0RgY=; b=c+IZud0ccovfOM+RR8f6
QW26htzkolxM2HOCcFNOTNZG0hiK10te5wStlVHKCXYxZE4/LY5N5IhZX0Tdc3KiZB3KyaFchi8Ef
BUCM13p71BzifCPpOe6+5iC87+shDZ0Y7iGB0NWkRnaP1tLnZ8tCwl3aRFsVnT+fipbNX293HEjmO
sxX+SLKXLiGj7T2NZEQL//sRNnDWgWl3j54FEX5xKwJsr2fzo3acQ8jtsoeyWHYVW94N7PTk7IJEI
/c65MhEnz6u0KZzMP4TjJXPEL7Jyk3bxqvkucWxHtHW6b0aLrIQpc7x7r/qe+XZh1hnqdFAN+f4H6
fql0pAZH6ASWOg==;
Date: Sat, 21 Mar 2026 10:55:37 +0200
Message-Id: <864im9d0ja.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN> (message from
Philip Kaludercic on Sat, 21 Mar 2026 08:25:38 +0000)
Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out
of eglot.el
References: <878qbym7rn.fsf@HIDDEN>
<CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN>
<202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN>
<CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN>
<873423l20g.fsf@HIDDEN>
<CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN>
<871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN>
<87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN>
<874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN>
<19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80595
Cc: 80595 <at> debbugs.gnu.org, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: 80595 <at> debbugs.gnu.org
> Date: Sat, 21 Mar 2026 08:25:38 +0000
> From: Philip Kaludercic <philipk@HIDDEN>
>
>
>
> On 20 March 2026 15:24:35 CET, "João Távora" <joaotavora@HIDDEN> wrote:
> >Philip Kaludercic <philipk@HIDDEN> writes:
> >
> >> João Távora <joaotavora@HIDDEN> writes:
> >>
> >>> Philip Kaludercic <philipk@HIDDEN> writes:
> >>>
> >>>> The first step is to adjust Eglot in such a way that major modes can
> >>>> indicate what LSP servers should be used. This doesn't mean removing
> >>>> any current features from Eglot, just adding something new. We can use
> >>>> the existing variable or come up with a new one, but that is it.
> >>>
> >>> You don't need any adjustment: if you don't want a e-s-program singular
> >>> variable (and maybe that's not a bad idea) just have the major-mode set
> >>> the e-s-programs plural variable buffer-locally. In fact I think at
> >>> least one major-mode already does this, or I suggested that it could do
> >>> it. I don't see any big problems with it.
> >>
> >> The complication here is that the major mode has to take into account if
> >> eglot has already been loaded or not. Not the end of the world, but an
> >> unnecessary complication.
> >
> >Sounds way less complicated to (require 'eglot) then to add a new variable
> >to eglot.el that has to follow precedence rules, etc.
>
> We can do that, but then everyone has to load eglot even if it is not necessary, which is what I was trying to avoid.
>
> >> Also, if the variable is buffer-local then we loose the ability to
> >> have a global lookup table of supported major modes and their servers
> >
> >Why? Why can't the mode use (default-value 'eglot-server-programs) to
> >get to the global database? Then again you say you want to set that
> >global value it to nil eventually, so again, your plan seems a total
> >mistery.
>
> No, I am suggesting to set the _default_ value to nil, so that you can populate it using global `add-to-list` calls.
Forgive me for suggesting something you've perhaps already considered
and rejected for some reason, but how about the following alternative:
. we add a buffer-local variable whose value gives the LSP server(s)
for the current buffer
. major modes could set this variable to name the LSP servers they
support
. Eglot will check this variable, and if non-nil, will use its value
in preference to what's in eglot-server-programs
I think this will allow the major modes which want to specify the
servers without any conflicts with eglot-server-programs. Or am I
missing something?
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.
Received: (at 80595) by debbugs.gnu.org; 21 Mar 2026 08:25:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 21 04:25:53 2026
Received: from localhost ([127.0.0.1]:39837 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w3reY-0007X3-C2
for submit <at> debbugs.gnu.org; Sat, 21 Mar 2026 04:25:53 -0400
Received: from mout01.posteo.de ([185.67.36.65]:39251)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <philipk@HIDDEN>)
id 1w3reU-0007Vn-Cd
for 80595 <at> debbugs.gnu.org; Sat, 21 Mar 2026 04:25:48 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 31C29240027
for <80595 <at> debbugs.gnu.org>; Sat, 21 Mar 2026 09:25:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017;
t=1774081539; bh=v42GNk+yYqKWQxY/uCfahFAqvIGT4QiTZdUv81HAh5I=;
h=Date:From:To:CC:Subject:Message-ID:MIME-Version:Content-Type:
Content-Transfer-Encoding:From;
b=dSkt4ew3M0x4PwbrqjN1JEERVhQn/6bYQLZcXmpfss7ibGYUR1mSq2L27dpK0GLcE
q/POaZkk/8aRjf/vOzzcOkUzSvU69iDsmJS4g1zLzE2H4IyKFQKA+/A9PAWLttMGRN
tBvBA8y/dUfmlbfoOiUa0nAf5pZNmfmO7Zmkeabr+tMswRIIGBwK45IbkX5koIezrR
LOHKv4u+50aEHzV5QB+2L6A7jtUSlNmZedN/PfPdUzgJ3I4PwggKSne+0QF8lhErPB
phakws4T5N6DCANDGoSLM5DHHoSJWSz4lL1yZc8pr61Av5dgX7mo5NmGED4sJwTzIh
S5qim3aNefGVw==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4fdCDd6Tx8z6twJ;
Sat, 21 Mar 2026 09:25:37 +0100 (CET)
Date: Sat, 21 Mar 2026 08:25:38 +0000
From: Philip Kaludercic <philipk@HIDDEN>
To: =?ISO-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN>
Subject: =?US-ASCII?Q?Re=3A_bug=2380595=3A_=5BPATCH=5D_Prepare_infrastru?=
=?US-ASCII?Q?cture_to_move_LSP_servers_out_of_eglot=2Eel?=
In-Reply-To: <874imashng.fsf@HIDDEN>
References: <878qbym7rn.fsf@HIDDEN>
<CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN>
<202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN>
<CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN>
<873423l20g.fsf@HIDDEN>
<CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN>
<871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN>
<87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN>
<874imbpp1k.fsf@HIDDEN> <874imashng.fsf@HIDDEN>
Message-ID: <19000DF6-4823-45F6-9D77-01FF546711ED@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80595
Cc: 80595 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
On 20 March 2026 15:24:35 CET, "Jo=C3=A3o T=C3=A1vora" <joaotavora@gmail=
=2Ecom> wrote:
>Philip Kaludercic <philipk@posteo=2Enet> writes:
>
>> Jo=C3=A3o T=C3=A1vora <joaotavora@gmail=2Ecom> writes:
>>
>>> Philip Kaludercic <philipk@posteo=2Enet> writes:
>>>
>>>> The first step is to adjust Eglot in such a way that major modes can
>>>> indicate what LSP servers should be used=2E This doesn't mean removi=
ng
>>>> any current features from Eglot, just adding something new=2E We can=
use
>>>> the existing variable or come up with a new one, but that is it=2E
>>>
>>> You don't need any adjustment: if you don't want a e-s-program singula=
r
>>> variable (and maybe that's not a bad idea) just have the major-mode se=
t
>>> the e-s-programs plural variable buffer-locally=2E In fact I think at
>>> least one major-mode already does this, or I suggested that it could d=
o
>>> it=2E I don't see any big problems with it=2E
>>
>> The complication here is that the major mode has to take into account i=
f
>> eglot has already been loaded or not=2E Not the end of the world, but =
an
>> unnecessary complication=2E
>
>Sounds way less complicated to (require 'eglot) then to add a new variabl=
e
>to eglot=2Eel that has to follow precedence rules, etc=2E
We can do that, but then everyone has to load eglot even if it is not nece=
ssary, which is what I was trying to avoid=2E
>> Also, if the variable is buffer-local then we loose the ability to
>> have a global lookup table of supported major modes and their servers
>
>Why? Why can't the mode use (default-value 'eglot-server-programs) to
>get to the global database? Then again you say you want to set that
>global value it to nil eventually, so again, your plan seems a total
>mistery=2E
No, I am suggesting to set the _default_ value to nil, so that you can pop=
ulate it using global `add-to-list` calls=2E
>>>> It doesn't appear to make much sense to be too concrete about the pla=
n
>>>> just now, since we need a general discussion and many of the details
>>>> will follow from the actual code changes we will make=2E
>>>
>>> No=2E You need a plan to address the questions I gave, else we're jus=
t
>>> wasting time=2E What do you annouce? Where? When? And what do you =
tell
>>> users that contribute a new server for eglot-server-programs after tha=
t
>>> point in time? IOW what do you do when someone submits this patch to
>>> bug-gnu-emacs@gnu=2Eorg?
>>
>> My point is that these questions very much depend on the course of
>> action we decide on following a discussion on emacs-devel=2E We need t=
o
>> understand our requirements before we deal with these edge-cases=2E At
>> the same time, I don't see the need for a fixed, a priori protocol to
>> deal with these situations=2E
>
>You are free to start whatever discussions you think, and I am free to
>ignore them, especially on Emacs devel where everyone and their cousin
>likes to pull opinions out their =2E=2E=2E=2E elbow and nothing actually =
gets
>made=2E The questions I asked above and below are the ones I think are
>relevant=2E If you can't/won't answer them, then I don't think there's a
>point in continuing the conversation=2E
If you are not interested in this, please say so=2E I pinged you because =
I assumed that you were interested and could provide useful input=2E
>>> diff --git a/lisp/progmodes/eglot=2Eel b/lisp/progmodes/eglot=2Eel
>>> index a4f076a6197=2E=2Ec6b66ac0f22 100644
>>> --- a/lisp/progmodes/eglot=2Eel
>>> +++ b/lisp/progmodes/eglot=2Eel
>>> @@ -274,6 +274,7 @@ eglot-server-programs
>>> ((c-mode c-ts-mode c++-mode c++-ts-mode objc-mode)
>>> =2E ,(eglot-alternatives
>>> '("clangd" "ccls")))
>>> + ((foo-mode foo-ts-mode) "foonix" "--stdio")
>>> (((caml-mode :language-id "ocaml")
>>> (ocaml-ts-mode :language-id "ocaml")
>>> (tuareg-mode :language-id "ocaml") reason-mode)
>>>
>>> Do you install it? Do you reject it and send them to foo-mode's and
>>> foo-ts-mode's developers=2E Do you go to the authors yourself? What =
if
>>> foo-mode lives outside emacs and foo-ts-mode in Emacs? What if the
>>> other way round? What do you tell the users stuck with Emacs 29 who a=
re
>>> loading Eglot from GNU-devel ELPA? "No oob foonix servers for you?
>>> Configure them yourselves=2E=2E=2E" Something else? Come to your dec=
isions
>>> on this, then ask for feedback of users=2E
>
>For reference, here are possible answers to these questions=2E
>
>Q1: Do you install it [in eglot=2Eel]?
>A1: No=2E
>
>Q2: Do you reject it and send them to foo-mode's and foo-ts-mode's
> developers=2E Do you go to the authors yourself?
>A2: Yes Emacs maintainers reject it, and apply an equivalent patch to
> the any in-tree major-modes directly=2E
>
>Q3: What if foo-mode lives outside emacs and foo-ts-mode in Emacs? What
> if the other way round?
>A3: For out-of-tree modes, authors are contacted=2E
>
>Q4: What do you tell the users stuck with Emacs 29 who are loading Eglot
> from GNU-devel ELPA? "No oob foonix servers for you? Configure
> them yourselves=2E=2E=2E"=2E Something else?
>A4: Yes exactly, GNU-devel ELPA/GNU elpa Eglot users lose the access to
> out-of-the-box setups of newest servers=2E They can more or less
> easily configure them anyway, or use a proxy server like Rassumfrassu=
m
> like rassumfrassum, which has its own database of preferred servers=
=2E
>
> As to the "something else", another idea is to make a complex build
> system for the Eglot :core package which could auto-generate a
> database of global-servers by collecting them from the in-tree
> major-modes where the patches were installed, but I (Jo=C3=A3o) won't
> work on that=2E
>
>Please, before you spawn follow up questions to my answers consider
>first making YOUR responses, to Q1-Q4=2E Really think through how you
>address these problems=2E
(I still don't see why it is important for me to make up my mind beforehan=
d=2E Going into discussions with a fixed-mindset is exactly how you get th=
e kind of impressions that you have of emacs-devel=2E)
>Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.
Received: (at 80595) by debbugs.gnu.org; 20 Mar 2026 14:24:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 20 10:24:40 2026
Received: from localhost ([127.0.0.1]:33597 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w3amF-0001fQ-Cm
for submit <at> debbugs.gnu.org; Fri, 20 Mar 2026 10:24:39 -0400
Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:54471)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>)
id 1w3am9-0001f1-Ve
for 80595 <at> debbugs.gnu.org; Fri, 20 Mar 2026 10:24:37 -0400
Received: by mail-wm1-x335.google.com with SMTP id
5b1f17b1804b1-4852a9c6309so5623655e9.0
for <80595 <at> debbugs.gnu.org>; Fri, 20 Mar 2026 07:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1774016672; x=1774621472; darn=debbugs.gnu.org;
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=dnvrZbtELV5AMXcGSNjcXrZDUXFXyXbg/HlHsiouH/0=;
b=GXaHmlT86kPJ6Edygxt1ZszcYK2TQ71xJFWeCOYzW9R14OlyjsuOMNj1twUycAsNDY
8CcF6B4S7LUUumCYMYE+v5eR0XmU7Wzt4i3JcNDiLZ347H+rKGfE2mha6r44mljEGvpU
Hl5KEvu8RTaR4fe8RUnnYf3uHLjSFK901XiQVID62XPslbBAqoO4j4AyKYtAIGRKPYaZ
wHvTql7bJ2EOLk/ImdAtoVnlX7UdoHZVF6Xv5yqp0qNKbt5zQhqd4geLBJ+hpxoOKw8m
NyYBgYd3qrezabT2UQl9a+Uw5nmHh08XfbZpmxrxY5OTInE9gGBpUvZXjd8sJuTFiSxW
If8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1774016672; x=1774621472;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=dnvrZbtELV5AMXcGSNjcXrZDUXFXyXbg/HlHsiouH/0=;
b=SiM3veDqndK8+ZxyJK74vXQhFTr8CTI7liTIrrvlgCuMBZ4+qf5fLwzoviYleV3eQt
Odh1uzQ+Z66rC8bQaCugD+/xEut0AmuauA1Zjtc7zyBwtVhwpYK63kZVkwllxy5EGFCu
eshSz1s6+7V3/wz3NQubDVSBsrTbRm8KWynF+NwLnubHYVEJqQVj20Dqjl5uwLb7Nwyj
7A43wPWQLd5f8RspJAWcB0W7wEhFcZuMtdO9Z6ahzYrl+t7KPx5lAIQPHQmFdKZGMgvz
Tu5+6p966HyI6c9XG7bbdSLaga3NQZhqXRkkaaC62AcL9a13hDxMHhSdFN4uWVNNle9N
fDIw==
X-Gm-Message-State: AOJu0YwvhTi+r3KZKHC4Bimj2YSCDHMjomgChbRQnYbEewcHcncRoWhg
HzJ5HFUWAHx+ECQT1jerLD70Bbr5yQOgtp4wMguPe9Duklajdruxdngfnz3HgQ==
X-Gm-Gg: ATEYQzxb4hw60HbpT+5HQWgpCErblio1Vbd4gHXw6SIJ2DILL07nhABRhO8LDYMpGxQ
RYQ7N5Js2ZPNhXXR/VftjtW+IaUXFtzoghOOSSZVYHK6ygEH3rWXYBJZBYjhVVG127nuVBv51ro
3IxBDOqzzLpH2EpmT8nUbdyqB3lOAy1IT1GhQPuVyxum08v2dm4j0+gouMExxdalm/YBtAvKAr2
OpEyYg6+142ptAmqavu/hg5mYd4IygQbXASKs4TbkRhTvVlZnnu15xqsSr4DYcGAXAyWOvtL9+U
ruLU4CguO+82X6aRBRqjfZ9nGBWHAesPr5RMHivMAd/p90zEAtms7KQgdVlKetHilomJdpUp529
nZL4IlpEWiiYGmFFVCU6+RxuOhpbCD48Inwxp8WKB5Z8+rYeRCYWVm7131EksWh/rhZCtk148+C
oGQHObEjQUjI0Q3VofOfPrD6PzClfw628xYRChH6syse/MoQce1iUkK/MIW4G6wu0TaP2g8t6Va
EciBfnlKtLMaAJ5gY7XzFjDaHo=
X-Received: by 2002:a05:600c:33a3:b0:486:ffa3:584 with SMTP id
5b1f17b1804b1-486ffa30b40mr18748075e9.15.1774016671776;
Fri, 20 Mar 2026 07:24:31 -0700 (PDT)
Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-486ff109b95sm46290015e9.1.2026.03.20.07.24.30
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 20 Mar 2026 07:24:31 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers
out of eglot.el
In-Reply-To: <874imbpp1k.fsf@HIDDEN>
References: <878qbym7rn.fsf@HIDDEN>
<CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN>
<202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN>
<CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN>
<873423l20g.fsf@HIDDEN>
<CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN>
<871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN>
<87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN>
<874imbpp1k.fsf@HIDDEN>
Date: Fri, 20 Mar 2026 14:24:35 +0000
Message-ID: <874imashng.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80595
Cc: 80595 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
Philip Kaludercic <philipk@HIDDEN> writes:
> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>
>> Philip Kaludercic <philipk@HIDDEN> writes:
>>
>>> The first step is to adjust Eglot in such a way that major modes can
>>> indicate what LSP servers should be used. This doesn't mean removing
>>> any current features from Eglot, just adding something new. We can use
>>> the existing variable or come up with a new one, but that is it.
>>
>> You don't need any adjustment: if you don't want a e-s-program singular
>> variable (and maybe that's not a bad idea) just have the major-mode set
>> the e-s-programs plural variable buffer-locally. In fact I think at
>> least one major-mode already does this, or I suggested that it could do
>> it. I don't see any big problems with it.
>
> The complication here is that the major mode has to take into account if
> eglot has already been loaded or not. Not the end of the world, but an
> unnecessary complication.
Sounds way less complicated to (require 'eglot) then to add a new variable
to eglot.el that has to follow precedence rules, etc.
> Also, if the variable is buffer-local then we loose the ability to
> have a global lookup table of supported major modes and their servers
Why? Why can't the mode use (default-value 'eglot-server-programs) to
get to the global database? Then again you say you want to set that
global value it to nil eventually, so again, your plan seems a total
mistery.
>>> It doesn't appear to make much sense to be too concrete about the plan
>>> just now, since we need a general discussion and many of the details
>>> will follow from the actual code changes we will make.
>>
>> No. You need a plan to address the questions I gave, else we're just
>> wasting time. What do you annouce? Where? When? And what do you tell
>> users that contribute a new server for eglot-server-programs after that
>> point in time? IOW what do you do when someone submits this patch to
>> bug-gnu-emacs@HIDDEN?
>
> My point is that these questions very much depend on the course of
> action we decide on following a discussion on emacs-devel. We need to
> understand our requirements before we deal with these edge-cases. At
> the same time, I don't see the need for a fixed, a priori protocol to
> deal with these situations.
You are free to start whatever discussions you think, and I am free to
ignore them, especially on Emacs devel where everyone and their cousin
likes to pull opinions out their .... elbow and nothing actually gets
made. The questions I asked above and below are the ones I think are
relevant. If you can't/won't answer them, then I don't think there's a
point in continuing the conversation.
>> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
>> index a4f076a6197..c6b66ac0f22 100644
>> --- a/lisp/progmodes/eglot.el
>> +++ b/lisp/progmodes/eglot.el
>> @@ -274,6 +274,7 @@ eglot-server-programs
>> ((c-mode c-ts-mode c++-mode c++-ts-mode objc-mode)
>> . ,(eglot-alternatives
>> '("clangd" "ccls")))
>> + ((foo-mode foo-ts-mode) "foonix" "--stdio")
>> (((caml-mode :language-id "ocaml")
>> (ocaml-ts-mode :language-id "ocaml")
>> (tuareg-mode :language-id "ocaml") reason-mode)
>>
>> Do you install it? Do you reject it and send them to foo-mode's and
>> foo-ts-mode's developers. Do you go to the authors yourself? What if
>> foo-mode lives outside emacs and foo-ts-mode in Emacs? What if the
>> other way round? What do you tell the users stuck with Emacs 29 who are
>> loading Eglot from GNU-devel ELPA? "No oob foonix servers for you?
>> Configure them yourselves..." Something else? Come to your decisions
>> on this, then ask for feedback of users.
For reference, here are possible answers to these questions.
Q1: Do you install it [in eglot.el]?
A1: No.
Q2: Do you reject it and send them to foo-mode's and foo-ts-mode's
developers. Do you go to the authors yourself?
A2: Yes Emacs maintainers reject it, and apply an equivalent patch to
the any in-tree major-modes directly.
Q3: What if foo-mode lives outside emacs and foo-ts-mode in Emacs? What
if the other way round?
A3: For out-of-tree modes, authors are contacted.
Q4: What do you tell the users stuck with Emacs 29 who are loading Eglot
from GNU-devel ELPA? "No oob foonix servers for you? Configure
them yourselves...". Something else?
A4: Yes exactly, GNU-devel ELPA/GNU elpa Eglot users lose the access to
out-of-the-box setups of newest servers. They can more or less
easily configure them anyway, or use a proxy server like Rassumfrassum
like rassumfrassum, which has its own database of preferred servers.
As to the "something else", another idea is to make a complex build
system for the Eglot :core package which could auto-generate a
database of global-servers by collecting them from the in-tree
major-modes where the patches were installed, but I (Jo=C3=A3o) won't
work on that.
Please, before you spawn follow up questions to my answers consider
first making YOUR responses, to Q1-Q4. Really think through how you
address these problems.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 19 Mar 2026 22:05:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 19 18:05:00 2026 Received: from localhost ([127.0.0.1]:49396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3LUB-00034y-Qq for submit <at> debbugs.gnu.org; Thu, 19 Mar 2026 18:05:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55246) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <rms@HIDDEN>) id 1w3LU8-00034K-84 for 80595 <at> debbugs.gnu.org; Thu, 19 Mar 2026 18:04:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <rms@HIDDEN>) id 1w3LU2-0004cR-Tq; Thu, 19 Mar 2026 18:04:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=jHELXNS3TEkSUpFs/+RuxzkeDqO721HcVtLbNLzJj/c=; b=BC8/0FFQErWb SO+4ncgMU4kUCVKZmKhtnSlnIL+w5mxrsXU8Htl6/TCoTAaHxrWVpysyITOrOWKJTvUcoWWipn4gJ wdoycviL4XhZwG1pRNSwiLL0uuHSXuvxhxDsLvWTaslrm8ZH4FHCELyVp+vT1mdNmqGauFhudsyv9 2sTy/7PpdZfGe5/sSQphHBLZ/6S+itL0q/ZNYkw+dRR0Jcd30E4VehTRkk3i0xoL2GsLFCNbN7p6B 6VSLbVtdda4ZMN+ovgnx1tW39vfxds5Qt43aAtbRfvyY7dlXRhN3znkztNHd3hHAzzdv0cGkwcYOF i7X/mKpyy203MAdN+uALgQ==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from <rms@HIDDEN>) id 1w3LTy-0006hZ-Kg; Thu, 19 Mar 2026 18:04:47 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman <rms@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> In-Reply-To: <87wlz9q6fd.fsf@HIDDEN> (message from Philip Kaludercic on Wed, 18 Mar 2026 19:33:11 +0000) Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> <87wlz9q6fd.fsf@HIDDEN> Message-Id: <E1w3LTy-0006hZ-Kg@HIDDEN> Date: Thu, 19 Mar 2026 18:04:46 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Reply-To: rms@HIDDEN Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The first step is to adjust Eglot in such a way that major modes can > indicate what LSP servers should be used. This doesn't mean removing > any current features from Eglot, just adding something new. We can use > the existing variable or come up with a new one, but that is it. > With this in place, we can start informing major mode maintainers about > the new feature. Depending on the details of the patch, this can > already start before we even release a version of Eglot that includes > the adjustments. If this change is simply a matter of moving some mode-specific data settings from Eglot to the individual major modes, I don't think it raises any issues except the technical ones. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.
Received: (at 80595) by debbugs.gnu.org; 19 Mar 2026 20:01:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 19 16:01:07 2026
Received: from localhost ([127.0.0.1]:49072 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w3JYI-0004vu-LL
for submit <at> debbugs.gnu.org; Thu, 19 Mar 2026 16:01:07 -0400
Received: from mout02.posteo.de ([185.67.36.66]:46865)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <philipk@HIDDEN>)
id 1w3JYF-0004u3-5x
for 80595 <at> debbugs.gnu.org; Thu, 19 Mar 2026 16:01:05 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 554E4240101
for <80595 <at> debbugs.gnu.org>; Thu, 19 Mar 2026 21:00:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017;
t=1773950456; bh=XJuKMAm5TK3CoSdi5DBT2jTgDS8zlfRa83OlbqIfEfs=;
h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version:
Content-Type:Content-Transfer-Encoding:From;
b=EtraUSwRIsx2HIoBHwpPyjOUwA4QMUsMIec5X6Ciw3lbA/BTjBGkydsTBhdqRpoh+
8yLLK3ttuY4UPEQb82YrXzfKBzE5bAu+wH0USTjBnkyYQeVw9hwJuAN2FuzaLQZj25
StzZLsmK0SGZ7WWMUjuXK8xF3i6HLNG7GeYrrv5Y84cyQmAEWgYZZdaHcSwSh+VL3E
WNu6CI1daM1ktrPMQ8IJEEFNUmhUakIX5pfeODx7qwE6GuU06CCrxZLs69loPNGhcC
OYQpf/QX6+xoDvYQb7Q8kSXF5TP4ohdirn0exwFzyylBrx5h0COMnQvM0Dl3TwcMaU
v3QiQrjraglmw==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4fcGlq5yQYz9rxF;
Thu, 19 Mar 2026 21:00:55 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers
out of eglot.el
In-Reply-To: <874imcu8y7.fsf@HIDDEN>
References: <878qbym7rn.fsf@HIDDEN>
<CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN>
<202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN>
<CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN>
<873423l20g.fsf@HIDDEN>
<CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN>
<871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN>
<87wlz9q6fd.fsf@HIDDEN> <874imcu8y7.fsf@HIDDEN>
OpenPGP: id=philipk@HIDDEN;
url="https://keys.openpgp.org/vks/v1/by-email/philipk@HIDDEN";
preference=signencrypt
Date: Thu, 19 Mar 2026 20:00:56 +0000
Message-ID: <874imbpp1k.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80595
Cc: 80595 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> Philip Kaludercic <philipk@HIDDEN> writes:
>
>> The first step is to adjust Eglot in such a way that major modes can
>> indicate what LSP servers should be used. This doesn't mean removing
>> any current features from Eglot, just adding something new. We can use
>> the existing variable or come up with a new one, but that is it.
>
> You don't need any adjustment: if you don't want a e-s-program singular
> variable (and maybe that's not a bad idea) just have the major-mode set
> the e-s-programs plural variable buffer-locally. In fact I think at
> least one major-mode already does this, or I suggested that it could do
> it. I don't see any big problems with it.
The complication here is that the major mode has to take into account if
eglot has already been loaded or not. Not the end of the world, but an
unnecessary complication. Also, if the variable is buffer-local then we
loose the ability to have a global lookup table of supported major modes
and their servers -- in which case we might as well use the singular
buffer local variable.
>> It doesn't appear to make much sense to be too concrete about the plan
>> just now, since we need a general discussion and many of the details
>> will follow from the actual code changes we will make.
>
> No. You need a plan to address the questions I gave, else we're just
> wasting time. What do you annouce? Where? When? And what do you tell
> users that contribute a new server for eglot-server-programs after that
> point in time? IOW what do you do when someone submits this patch to
> bug-gnu-emacs@HIDDEN?
My point is that these questions very much depend on the course of
action we decide on following a discussion on emacs-devel. We need to
understand our requirements before we deal with these edge-cases. At
the same time, I don't see the need for a fixed, a priori protocol to
deal with these situations.
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index a4f076a6197..c6b66ac0f22 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -274,6 +274,7 @@ eglot-server-programs
> ((c-mode c-ts-mode c++-mode c++-ts-mode objc-mode)
> . ,(eglot-alternatives
> '("clangd" "ccls")))
> + ((foo-mode foo-ts-mode) "foonix" "--stdio")
> (((caml-mode :language-id "ocaml")
> (ocaml-ts-mode :language-id "ocaml")
> (tuareg-mode :language-id "ocaml") reason-mode)
>
> Do you install it? Do you reject it and send them to foo-mode's and
> foo-ts-mode's developers. Do you go to the authors yourself? What if
> foo-mode lives outside emacs and foo-ts-mode in Emacs? What if the
> other way round? What do you tell the users stuck with Emacs 29 who are
> loading Eglot from GNU-devel ELPA? "No oob foonix servers for you?
> Configure them yourselves..." Something else? Come to your decisions
> on this, then ask for feedback of users.
>
>>>> this is true, without any other precautions situations like these could
>>>> take a while. do you know of any historical examples that i could
>>>> mention on the emacs-devel discussion? i am assuming we are talking
>>>> about situations where it wouldn't make sense for mode b to just inher=
it
>>>> all servers from mode a?
>
> Just looks at the modes list. There are some entries where there are
> unrelated modes from different vendors but for the same (or related)
> languages. tuareg-mode and ocaml-mode and reason-mode above.
OK, will do.
> Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.
Received: (at 80595) by debbugs.gnu.org; 18 Mar 2026 21:25:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 18 17:25:03 2026
Received: from localhost ([127.0.0.1]:34260 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w2yNz-0007zF-8B
for submit <at> debbugs.gnu.org; Wed, 18 Mar 2026 17:25:03 -0400
Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:51490)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>)
id 1w2yNw-0007ye-R0
for 80595 <at> debbugs.gnu.org; Wed, 18 Mar 2026 17:25:02 -0400
Received: by mail-wm1-x32b.google.com with SMTP id
5b1f17b1804b1-48558d6ef83so2256435e9.3
for <80595 <at> debbugs.gnu.org>; Wed, 18 Mar 2026 14:25:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1773869099; x=1774473899; darn=debbugs.gnu.org;
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=//Tnx7xlHi5JrKGu9Cdz+9MFdggxTylw+rup5H1cEJs=;
b=lNaxJ9wg25hObKTZamF72xt0dxP+aK9agKChwLuqjyVwjq8KPeii380syA3a0z81t4
rFHCfhg8ZihSfeT48oE3VUxiL/DZbWfVBweYL9cyYGNpGTIqurJi9GTP43pFhxlXSxP9
m9MtVHs3sa/1ksQmf9w6QPfZhK59t2J1Jjo4q7WsAd7Q/FCwYvZaokK7rO+4HJGoY6m/
vTX7ujKskJu9KI8lFvEzOLxX90P1s7B1EYZQiRSSxB029syjr63HGgjcrXxotw9nbsf2
H/+n+/zPPu450PIyygk7pu7ZvyUZFrl9D+PMTSKwscHADC1/xW9YG/auHmUhZwkq/WP1
OvTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1773869099; x=1774473899;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=//Tnx7xlHi5JrKGu9Cdz+9MFdggxTylw+rup5H1cEJs=;
b=STLOTOcHUQMvzlI4rVkMO7vO65dkBCfzu8VHmkvO6xi4KauGdViA2bcPAduVRST0xO
zfM2afL+KWywi/rTnvZxsmfgzk9UnHCqZ7IiUFlPVEG2jyC3NfHAjbV5GuP6DEmfGAF+
TdjcFgFvuWiUKPrWaphXa+Ree/mrhCbEHlkpJHC8EAt2FlIEbCl5nMvuNjYQe5ydnofH
sXNqsrHzfwICmVHFyf4iSWBNMHnyc/XJU1VpFPtN3KngR8VrzVKXstOo1/8IhOPudfAo
0PoKDzfTiEKLm2Owhtc76qFsJcFUFHsqz0OA/QoHzjoeuX8ndGGmrbfd5WsBua0yk0kY
rGbw==
X-Gm-Message-State: AOJu0YxuNvDe0nyMLwKmxZx/+lB9JL0EizKHNaI9IoRqC34sTeRCoojl
S91oC4FTSYyEKJw56wkAJe5DeyPA2OP0ipgSSyhS42/ujTtWb5yZhumzArAnLg==
X-Gm-Gg: ATEYQzwXzfLM8dxXVt8lIp/QQUvslOEbU2p4CkCimltVQJ/C+BA8qbr4Yg8FTXAeRpU
Ju2LoaHMKNeDO2rC0eenx/UfcPmGQPzhlYh4/215r7iUlH9rgkOnx8xTc/XATD8OPddKv0lJWci
BkA/jzuUUdEQPR2MJg3hLdRo3c17cLtXBgvbN+YVzr8b7XxSZZZgl0IapukuAtjx2YqDgn2cPdB
7ZfiuMYr9wTueREUStJ3dRYcNWchlWEMLCh+ir2g3/TQFOcLFa89CM/M5cEFYlbOe1U0mAEw4iu
TqhlqauBDblqHYTNtW3uV4Lg9zTGedqFaj/xYYjIBVX+a7PXFWC+y50MhGwclG5+Z/OheIn7oNv
t0cQ5/jFuL5NCY7PVzHGPNKJw1CqboKaNwioCBJwRBsboIv5xQ1R9oatuAOJgnI5d5gvvpsphvV
mPrPgM64HUxg0Q4wNSajV0lj1LUIlDwnDV8/BYuwPL2ZN1gaRFaPNutFyMY23leeP3NLfzmYdAp
UNCgVV5inVw+UL6JteiNYcgU1FifQ0LYweh9A==
X-Received: by 2002:a05:600c:2d09:b0:486:af22:4a2a with SMTP id
5b1f17b1804b1-486f44221bamr49975385e9.7.1773869099061;
Wed, 18 Mar 2026 14:24:59 -0700 (PDT)
Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-486fa35b147sm8088515e9.15.2026.03.18.14.24.58
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 18 Mar 2026 14:24:58 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers
out of eglot.el
In-Reply-To: <87wlz9q6fd.fsf@HIDDEN>
References: <878qbym7rn.fsf@HIDDEN>
<CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN>
<202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN>
<CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN>
<873423l20g.fsf@HIDDEN>
<CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN>
<871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN>
<87wlz9q6fd.fsf@HIDDEN>
Date: Wed, 18 Mar 2026 21:25:04 +0000
Message-ID: <874imcu8y7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80595
Cc: 80595 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
Philip Kaludercic <philipk@HIDDEN> writes:
> The first step is to adjust Eglot in such a way that major modes can
> indicate what LSP servers should be used. This doesn't mean removing
> any current features from Eglot, just adding something new. We can use
> the existing variable or come up with a new one, but that is it.
You don't need any adjustment: if you don't want a e-s-program singular
variable (and maybe that's not a bad idea) just have the major-mode set
the e-s-programs plural variable buffer-locally. In fact I think at
least one major-mode already does this, or I suggested that it could do
it. I don't see any big problems with it.
> It doesn't appear to make much sense to be too concrete about the plan
> just now, since we need a general discussion and many of the details
> will follow from the actual code changes we will make.
No. You need a plan to address the questions I gave, else we're just
wasting time. What do you annouce? Where? When? And what do you tell
users that contribute a new server for eglot-server-programs after that
point in time? IOW what do you do when someone submits this patch to
bug-gnu-emacs@HIDDEN?
diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index a4f076a6197..c6b66ac0f22 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -274,6 +274,7 @@ eglot-server-programs
((c-mode c-ts-mode c++-mode c++-ts-mode objc-mode)
. ,(eglot-alternatives
'("clangd" "ccls")))
+ ((foo-mode foo-ts-mode) "foonix" "--stdio")
(((caml-mode :language-id "ocaml")
(ocaml-ts-mode :language-id "ocaml")
(tuareg-mode :language-id "ocaml") reason-mode)
Do you install it? Do you reject it and send them to foo-mode's and
foo-ts-mode's developers. Do you go to the authors yourself? What if
foo-mode lives outside emacs and foo-ts-mode in Emacs? What if the
other way round? What do you tell the users stuck with Emacs 29 who are
loading Eglot from GNU-devel ELPA? "No oob foonix servers for you?
Configure them yourselves..." Something else? Come to your decisions
on this, then ask for feedback of users.
>>> this is true, without any other precautions situations like these could
>>> take a while. do you know of any historical examples that i could
>>> mention on the emacs-devel discussion? i am assuming we are talking
>>> about situations where it wouldn't make sense for mode b to just inherit
>>> all servers from mode a?
Just looks at the modes list. There are some entries where there are
unrelated modes from different vendors but for the same (or related)
languages. tuareg-mode and ocaml-mode and reason-mode above.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 18 Mar 2026 19:33:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 18 15:33:22 2026 Received: from localhost ([127.0.0.1]:33834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2wdt-0000Uw-Uc for submit <at> debbugs.gnu.org; Wed, 18 Mar 2026 15:33:22 -0400 Received: from mout01.posteo.de ([185.67.36.65]:51055) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1w2wdq-0000Ub-Q2 for 80595 <at> debbugs.gnu.org; Wed, 18 Mar 2026 15:33:20 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id C5EE4240027 for <80595 <at> debbugs.gnu.org>; Wed, 18 Mar 2026 20:33:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1773862391; bh=TLN4N8hwnqaIOVCqgd5MF78lueushuiQ3OI2BgJwvtg=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=XxFjX1I3KTKpakgJhtH6pcRL+Q75SKj7VKyCdXQP7jGqwoJquyaYRouF8OcAQ5ItW INSS/xffCx59ST77CQwkxubx8O71/eu2uQrYrz7WQc+t9zi4NzPWs0/SVCApuodiPD B9RKwt7FTe9yG5gzo0Bkm1/T/cNagVkmTCtbX6DRu12uyX8Z+bpGbrIbW94NVjBek2 PwVtdv9tfsc8Xifyj2S17f9G8XagewyyZlyzOV/ESUuWOmwLfjXCWpuWOiKwdcJSJJ ip4oBtTdsGTBpgySl2POIOFnqXZmlJ3fX6b/BbaJRr2PuijWl2nhferfQeBP+D2cg2 0kJI2X5A/vAAQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fbfBH11tSz6tvy; Wed, 18 Mar 2026 20:33:10 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el In-Reply-To: <87o6kmt5xj.fsf@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> <87o6kmt5xj.fsf@HIDDEN> OpenPGP: id=philipk@HIDDEN; url="https://keys.openpgp.org/vks/v1/by-email/philipk@HIDDEN"; preference=signencrypt Date: Wed, 18 Mar 2026 19:33:11 +0000 Message-ID: <87wlz9q6fd.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Philip Kaludercic <philipk@HIDDEN> writes: > >> My "endgame" is to have major modes configure what LSP servers+options >> Eglot should try out, just like how we don't maintain `auto-mode-alist' >> in Emacs and ask all packages to register their major modes with us. A >> consequence of this is that we might eventually be able to set >> `eglot-server-programs' to nil, but that is not _my_ primary interest. > > I'm still confused. You need a concrete step by step plan of what you > want to do, what changes to eglot.el, what policies to implement, when, > what to tell contributors of new servers for language L and major modes > X, Y, and Z that handle that language, what to tell users of GNU ELPA > Eglot, etc. The first step is to adjust Eglot in such a way that major modes can indicate what LSP servers should be used. This doesn't mean removing any current features from Eglot, just adding something new. We can use the existing variable or come up with a new one, but that is it. With this in place, we can start informing major mode maintainers about the new feature. Depending on the details of the patch, this can already start before we even release a version of Eglot that includes the adjustments. All of this would ideally be transparent to users, and they wouldn't have to notice anything. It doesn't appear to make much sense to be too concrete about the plan just now, since we need a general discussion and many of the details will follow from the actual code changes we will make. It would also be great if you could respond to this question from my last message: >> >> > What if t= wo quite >> >> > different modes from different vendors would benefit from the same = server >> >> > invocation? >> >> again, i don't understand the exact problem here. you have much more >> >> experience with these kinds of problems that i do, so perhaps it is >> >> obvious to you, but i don't see why both couldn't specify the same >> >> server invocation. >> > >> > some completely unrelated modes a and b for the same language can use >> > the same server x. are you going to forward the new x addition to all= of these >> > authors? depending on the authors' availability, adoption could take = some >> > time. again, currently the server invocation is added to eglot and all >> > modes old or not can take advantage of it, as long as eglot is updated. > >> this is true, without any other precautions situations like these could >> take a while. do you know of any historical examples that i could >> mention on the emacs-devel discussion? i am assuming we are talking >> about situations where it wouldn't make sense for mode b to just inherit >> all servers from mode a?
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 17 Mar 2026 23:03:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 17 19:03:20 2026 Received: from localhost ([127.0.0.1]:51926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2dRX-0004l9-St for submit <at> debbugs.gnu.org; Tue, 17 Mar 2026 19:03:20 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:49646) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w2dRU-0004kv-Fo for 80595 <at> debbugs.gnu.org; Tue, 17 Mar 2026 19:03:17 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4838c15e3cbso57160935e9.3 for <80595 <at> debbugs.gnu.org>; Tue, 17 Mar 2026 16:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773788595; x=1774393395; darn=debbugs.gnu.org; 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=dPn4p3wnlelwG1653YTuUGuy/DD3SPi4eSrbmxsqFxs=; b=L/Pr59QC+0pjk4aw5EwULOjJGSH5uf0ShnYdllr/B2/LO86jtlMAeGknx/U9UuuqXl 1PIby7g3mHnJac68l4Mfb8Hvhpo8zwmbZTac8OvaveZ4ZGVJy9eiO8nCXEOoLFBbarkJ UkNHVOWLjleMX/p2JL/jWomdHb4btJxXRA51S+d0GuGjLB1E133zEjz3jsM58q6JOxJB AmcudD7j2lNyv2MMVSaJVRI9ib7xVZST4XHu41GnMKU5KFc3/SiGpmYrjf13TXGriQq/ /DLBTFeI8v16ajNEqR9wKpAM5YsfOhenNX44HqsHTxNlDMz0eWwIZ+P92TNhF4dFFgov tLAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773788595; x=1774393395; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dPn4p3wnlelwG1653YTuUGuy/DD3SPi4eSrbmxsqFxs=; b=lUgiSX4HUuOpuuC47gPgZhw3LU+pPjxFrLXbYPi6KqXLm+vGGecoUBIna6TTb/lewn FrSmiRHWSGdZ6m5oYzmmLwTgmYr6XJQJ15Qi+IxqzcvmaA62LCt/qvN6SB7EcJ8tsJ4u 0k9Ux7h5MSwLAnJSXMLw6Q6M0vmCsIVp4FSQmzGpkJf0Ur8GZfMX2xz9w9Rn98PSEHJD WXwEi4NDQp3aJPzc+oNHsVZcGfeo8ytRZFfVfxco8SWp6DQvVJ2ct0kuKm2RRgEC9L1q tVlJqAA6hOtFbSDCl6re1GQNLOPHOhfgyJuV+VjZ2z2krci9wKRZtX38Wkxs8/pgN9oW E6dg== X-Gm-Message-State: AOJu0YwSV7jyg8lH4PAiqBBG+vFiAJbh7yQvPCEm8sdNcXrx2QMvbAOn 6nwHewW0B8tj2IVsIJD/d2Xj43ZQnBLlqXetX1htmVio5+PV9IwRep9/cBFw4A== X-Gm-Gg: ATEYQzz/EO31K1+jaHh5wNo51g2ADPCYtH43P7Url/g+hPm20HjC3jfzDeF6bM+GiIt WB0XeBlEkD25mPtSCXvIEk5rpmqgWsvDX9hXrMoAZW86F/KlEzxzCi1BN3Hw4/6cil9cjinREWo OTHqKepLOvB07wAwk6e6g+kIgYcxGA7HqV0hkY1PNWamorNKOiGbXCKR1riCeN4JoWCMc4bFR8K CPe9cQb6qWYFW2ifflZFbFVWnfwNQbD+GhTR0pAcu7LLNtbOMywFAIGDfiz5iqcUk0s/UZcdyIy a2zfjLOVCYPKJ+yGnY+WkHRPAxWVixS5SI4z002OiJW7kRs+8RF8/Sir00UnjI0bv7pd6ZGhzvJ 5QN+mFjDvB9WTxFjsxx6TV9hdciIC6oNivk/TV/HSgoUR1GqjE3MbyVxOTefKvXMCxRSwjRP9au KRKVhJ/nIcLoI+jHAnVdWM36BlZDvPbhfvHEspYxFadv1hmT0ngWcB3u2ThfOgohIsZpLqmKQe1 VNf+nvcUQ4SD7qlqSqJYaIRFms= X-Received: by 2002:a05:600c:630a:b0:483:c35d:3659 with SMTP id 5b1f17b1804b1-486f4448621mr22428095e9.18.1773788594799; Tue, 17 Mar 2026 16:03:14 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486f443ae26sm20232775e9.14.2026.03.17.16.03.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 16:03:14 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el In-Reply-To: <871phmkajo.fsf@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> <871phmkajo.fsf@HIDDEN> Date: Tue, 17 Mar 2026 23:03:20 +0000 Message-ID: <87o6kmt5xj.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Philip Kaludercic <philipk@HIDDEN> writes: > My "endgame" is to have major modes configure what LSP servers+options > Eglot should try out, just like how we don't maintain `auto-mode-alist' > in Emacs and ask all packages to register their major modes with us. A > consequence of this is that we might eventually be able to set > `eglot-server-programs' to nil, but that is not _my_ primary interest. I'm still confused. You need a concrete step by step plan of what you want to do, what changes to eglot.el, what policies to implement, when, what to tell contributors of new servers for language L and major modes X, Y, and Z that handle that language, what to tell users of GNU ELPA Eglot, etc. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 14 Mar 2026 09:47:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 05:47:27 2026 Received: from localhost ([127.0.0.1]:52559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1Lad-0001au-Ds for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:47:27 -0400 Received: from mout01.posteo.de ([185.67.36.65]:46779) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1w1LaU-0001Rq-Fd for 80595 <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:47:20 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 56635240027 for <80595 <at> debbugs.gnu.org>; Sat, 14 Mar 2026 10:47:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1773481628; bh=GNazK/lV5BM5Ny7RSvjCdDiiGehNJFiT7rPQBp2TmV8=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=plv7OoibCNg3PgNgECOH3UGfYgIl6qnIoVVT8YbtLNdvcMtIiDxNLnj5Wt/Ufd5Qn 0mZTiiyvVVkvaysMk7Hbbrt4GcMTtOlA0sbyArg6ZojKfVS9MtN9mTbw1Sl45LL78F LhkoOTnmDzZKle8b0JWwaSPcUSrlrwKkpznR6/PW49ygPx+gfFsoD+316IwYDWVbC3 KJZKCyyq/luZ2wHRJkAfTl8odS1oeVOjxUK5ImJCRLKnfTkePjGnpRhBsbZmkrlEyl ZOGQ+iNgx9gz9ByZ+LkbXL7xP/oseEfK/LzKvbfJ0VPR0swhWpqkm0+9TKP2lB9m3G A8Wb8xsk2fHCw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fXxMv5CjNz6tvq; Sat, 14 Mar 2026 10:47:07 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el In-Reply-To: <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> OpenPGP: id=philipk@HIDDEN; url="https://keys.openpgp.org/vks/v1/by-email/philipk@HIDDEN"; preference=signencrypt Date: Sat, 14 Mar 2026 09:47:07 +0000 Message-ID: <871phmkajo.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > On Fri, Mar 13, 2026 at 11:53=E2=80=AFPM Philip Kaludercic <philipk@poste= o.net> wrote: > >> > Therefore, if Emacs 31 is where you want this to happen you must imagi= ne a >> > major version 3x happening where you _remove_ the eglot-server-programs >> > variable or at least its content. I suppose you would deprecate that >> > variable before doing that. Now in 31? In some 3y between 31 and 3x? >> >> In my current proposal we don't have to deprecate the >> eglot-server-programs variable. > > So you leave the value frozen in the current state forever? We don't have to deprecate the _variable_, the hope is to eventually be able to have the _value_ just set to nil.n > Do you keep the variable's value or set it do nil. > Or do you let it grow just like it does now and simply have > any presumably smarter mode-local value of 'eglot-server-program' (singul= ar) > override it?=20=20 My plan was never to introduce a "singular" variable, but I recall you suggesting it. I think a global variable that packages can extend at autoload time is better, since that gives us a central index of all supported major modes and their servers. I was looking into how difficult it would be to add a command like Helix' "--health" flag, that checks the availability and features of all known LSP servers, and that would be more difficult to implement if LSP support were to be hidden within major mode definitions. > In that case how is that different from having that major-m= ode > simply set a local value for 'eglot-server-programs' (plural) in its mode > function? > > Seems like I have not understood your "endgame". I thought you wanted > to relieve eglot.el of having that clunky big list of servers, some stale= , some > half-functional. My "endgame" is to have major modes configure what LSP servers+options Eglot should try out, just like how we don't maintain `auto-mode-alist' in Emacs and ask all packages to register their major modes with us. A consequence of this is that we might eventually be able to set `eglot-server-programs' to nil, but that is not _my_ primary interest. >> > And in all that time between Emacs 31 and 3x, what do you do when patc= hes >> > come in asking for out-of-the box support for a new server/new major m= ode? >> > This is the most frequent change to Eglot. So what do you do? Reject i= t and >> > suggest to put it into the mode (s)? Accept it into the deprecated >> > variable? Put it both in the deprecated variable and in the major mode? >> > What if that mode doesn't live in Emacs core or GNU ELPA? >> >> What is the issue with pointing contributors to the major mode, >> wherever it might be maintained? That would have been my go-to answer, >> but you make it seem like there is something we are forgetting. > > Yes. Then someone brings a new server X for mode Y. You point that some= one > to the mode Y's maintainers, and mode Y adds the server in their latest v= ersion. > Then someone updating Eglot will not be able to use server X by updating > Eglot unless they also update mode Y. What if the new version of mode Y > doesn't work for your version of Emacs? Ah I understand, it took me two attempt to get the point: If a major mode stops supporting an older version of Emacs, that Eglot still would, then a user stuck on that older version of Emacs wouldn't find out about new LSP servers, right? My take here is that major modes usually don't need the newest Elisp features, and hence are in a good position not to bump the oldest version of Emacs that they support. Compat certainly tries to help here as well. But when push-comes-to-shove, it is not the end of the world for a user to add a `add-to-list' call in their init.el. I'd like to make that easier as well, after all. >> > What if two = quite >> > different modes from different vendors would benefit from the same ser= ver >> > invocation? >> Again, I don't understand the exact problem here. You have much more >> experience with these kinds of problems that I do, so perhaps it is >> obvious to you, but I don't see why both couldn't specify the same >> server invocation. > > Some completely unrelated modes A and B for the same language can use > the same server X. Are you going to forward the new X addition to all of= these > authors? Depending on the authors' availability, adoption could take some > time. Again, currently the server invocation is added to Eglot and all > modes old or not can take advantage of it, as long as Eglot is updated. This is true, without any other precautions situations like these could take a while. Do you know of any historical examples that I could mention on the emacs-devel discussion? I am assuming we are talking about situations where it wouldn't make sense for mode B to just inherit all servers from mode A? >> > Anyway, put a link to that discussion in the GitHub discussion forum. = When >> > the discussion settles, write the resulting policies as a comment in >> > eglot.el. Consider also the change to Eglot's GitHub README.md which is >> > where many people first take contact with Eglot. >> >> Sounds good, do you want me to CC you? > > Yes, but before you even start the discussion, come to a personal decision > on how you want to deal with the above problems. I still would prefer major modes to configure the servers, but I now better understand the potential pitfalls, so thank you! > Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 14 Mar 2026 01:47:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 21:47:02 2026 Received: from localhost ([127.0.0.1]:49756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1E5j-000530-FF for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 21:47:02 -0400 Received: from mail-oa1-x29.google.com ([2001:4860:4864:20::29]:53684) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1E5g-00052K-5u for 80595 <at> debbugs.gnu.org; Fri, 13 Mar 2026 21:46:58 -0400 Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-40efc77933fso1775877fac.3 for <80595 <at> debbugs.gnu.org>; Fri, 13 Mar 2026 18:46:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773452815; cv=none; d=google.com; s=arc-20240605; b=U8td1OMpa5ZCltg24TD7lywcxH86M9gWx+P2LMJBVjso1c+7DslBbVzeQ7RkKMb+Md ID1BU3zAfHU2epSZ7uHwRNe2+F8qSLy55V/tcdtGfl9OCMQ3TXY7R1oDaiGHaHxAXKNf im6gKp3TdfII8p0bozVTYAX9FtNwJ6yh+V8XRT/9qJGVnXXIchg6PN/DdYc+bYx95Ng1 F0T9JlnpBbeWNf+EvqU6y5qjnqxqBU+HArf3+RVnrJ3J7xOSAwuvvh/70Y2xRV9VcAZo Fqk+mlou86WMGOYrFGqTlH1TlJozyHZnNzyBy8TLDDzHngI/4Ez5CtAPhQYRB0CsCIVX uC8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RyV39YbpzDrJzkHqfZSvDaxe4xDrUvznqDumxpfRw9s=; fh=b859ATIaHQbn1h2Zb2PkubzK/ZkVpYJnuwlYhXVatDA=; b=TiTQs6Pn95hdzqqeAUZXke8gfaVgxCuqhM1m4u6w0Opzgk6yDAd/Hk9Gc0xpniiwI1 iA/fRQoi/QBNwjUFBerZ3f6+9T8MwXP4RyXHwsrDLEXkFZSrizBznJ13xC5UH3ZB5471 cTHpgKKL8c8ATE4qQPSFdOeI7iRAn7gHYW1k748l4Tpxpd0naSbv/WTYAiQFi6IHaJwa EJUmrsOwvxULOQ1btxLSJKqSw4GPykTjENU1TRdFMsO9PI65G2uQWRkLdU6XMhbE0/Ay jxBwoLKWFO4LDFMd2OUT7UutWQta1jalOYAd+b1LSmd7bpTIdWA1gI/5BEaaEaK7DgYw 8bhA==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773452815; x=1774057615; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RyV39YbpzDrJzkHqfZSvDaxe4xDrUvznqDumxpfRw9s=; b=iJvTw9K6maQBBRgdYCTa4aicOwWQCzh9YRM6lCDB4rQ3xhyb273ytAxSwrpKl1bHNo ToQee0hTu2f1v/AQxuLa9IDY4NrACmLrFW3tFnGz2lkES/eQXP1sYcsJgOFVg+aKeiw4 TCltcO/+26Z8V4bZJ/BEk78vlOFieVJghuVsrLaz7unMTPYaYINUkhD0gcHduej+ZnIK gyHdOTX1+G/xYN6rzytONC03syF5bFNP8MMMdrq68nTj3ZFc8b7i0hh6p2SGVEFUhdRH TOzSjquLoBhaRRpfVeQqwnLkROZDoEnO0ml4M6OlvcrtAoBUvtx6ojUYCcAv7a+/4rct GOBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773452815; x=1774057615; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RyV39YbpzDrJzkHqfZSvDaxe4xDrUvznqDumxpfRw9s=; b=btAf3kGq/qVmH6ULo3zWNQRi/Z11VWjBnLtZZ8ZvG2ayZWh+u1L5S844glsd8AtRh3 U754rdVJOVEw8XDghC4amUiBzvWGckk65smElYbTm+3PKP9/ZxV9XkFz9YRDlq9euIVb WU8ES73WuuGhNBa/DwcyqpQVQIA1PTSzL94B+UrWTF4892SHJMVVc06o/4XgfdK0YGES QakxDnPkyeTdn4/QAaIxYKNd3fguTXF9H3LXbTNuVH+SxNNYgzlHn1+Ps/nzQyOrGPsW A5mgiS4O8IAoAa4Uw/v0uQtTrHZnOqiCVYTiGya+DJYKD33QgVs+NjZEMeCWSt8ecEBZ bZRA== X-Gm-Message-State: AOJu0YxZAVlY5n1SRml/QH/tlL7FIaCGpEv/SzSz9pRrBBTigSfvLR6v hpiG3Op9KOzP7+LnBTC/chCLyD+Sy00h3hZ7D8TQSotFArNPbqZhG9W1J86GjCAnTDx4HyB45BN Ey5FJ3sZhpy4S5eAgXPbeb/BBR3hgW3oIBg== X-Gm-Gg: ATEYQzyw9AuiOg7MjDy2fEncRdqL9GlpGx/KsjeeDXGqVACE2K6Q6FDPWcmNNsQBR1T 4ZchcnYP7NeR4gFPR+kdO4PAM5xMAxk66CYm5FksbgAN/kn/5O7kG/VaILb2JyeLKqvkIhZ2nKr H56xTzdLxGOOA9jrVDiwcm76oSRDOeoAOoenA46G0Tf2KZ75HGPINKwPzuamKgkjlZIpCr73hCJ GmdZv9nXbz/lIE5d34Mz/ngoViYM1aP5eNa2HeKSAs3DhWm0hyl+iGui/fXENpthWuwch1UNeLj 3pczRvcK9it/hpGJIHJ3kTEaWtpi+U+CDLwlMA//ImJ5Es854O0f5GJRkIEp4BkWU5k= X-Received: by 2002:a05:6871:411:b0:417:b01:2239 with SMTP id 586e51a60fabf-417b92b0decmr2717445fac.22.1773452814701; Fri, 13 Mar 2026 18:46:54 -0700 (PDT) MIME-Version: 1.0 References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> <873423l20g.fsf@HIDDEN> In-Reply-To: <873423l20g.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Sat, 14 Mar 2026 01:49:54 +0000 X-Gm-Features: AaiRm538hXbWsLXB0SnJT3pOBpbSTGpnLteZg_vOtWnvnpdiVNSI6-xGLX4dxig Message-ID: <CALDnm53ZkapfVz=mXJ56onnsNnb1Uo=rr3wa_vRDfm2REyAR-g@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el To: Philip Kaludercic <philipk@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) On Fri, Mar 13, 2026 at 11:53=E2=80=AFPM Philip Kaludercic <philipk@posteo.= net> wrote: > > Therefore, if Emacs 31 is where you want this to happen you must imagin= e a > > major version 3x happening where you _remove_ the eglot-server-programs > > variable or at least its content. I suppose you would deprecate that > > variable before doing that. Now in 31? In some 3y between 31 and 3x? > > In my current proposal we don't have to deprecate the > eglot-server-programs variable. So you leave the value frozen in the current state forever? Do you keep the variable's value or set it do nil. Or do you let it grow just like it does now and simply have any presumably smarter mode-local value of 'eglot-server-program' (singular= ) override it? In that case how is that different from having that major-mod= e simply set a local value for 'eglot-server-programs' (plural) in its mode function? Seems like I have not understood your "endgame". I thought you wanted to relieve eglot.el of having that clunky big list of servers, some stale, = some half-functional. > > And in all that time between Emacs 31 and 3x, what do you do when patch= es > > come in asking for out-of-the box support for a new server/new major mo= de? > > This is the most frequent change to Eglot. So what do you do? Reject it= and > > suggest to put it into the mode (s)? Accept it into the deprecated > > variable? Put it both in the deprecated variable and in the major mode? > > What if that mode doesn't live in Emacs core or GNU ELPA? > > What is the issue with pointing contributors to the major mode, > wherever it might be maintained? That would have been my go-to answer, > but you make it seem like there is something we are forgetting. Yes. Then someone brings a new server X for mode Y. You point that someon= e to the mode Y's maintainers, and mode Y adds the server in their latest ver= sion. Then someone updating Eglot will not be able to use server X by updating Eglot unless they also update mode Y. What if the new version of mode Y doesn't work for your version of Emacs? > > What if two q= uite > > different modes from different vendors would benefit from the same serv= er > > invocation? > Again, I don't understand the exact problem here. You have much more > experience with these kinds of problems that I do, so perhaps it is > obvious to you, but I don't see why both couldn't specify the same > server invocation. Some completely unrelated modes A and B for the same language can use the same server X. Are you going to forward the new X addition to all of t= hese authors? Depending on the authors' availability, adoption could take some time. Again, currently the server invocation is added to Eglot and all modes old or not can take advantage of it, as long as Eglot is updated. > > Anyway, put a link to that discussion in the GitHub discussion forum. W= hen > > the discussion settles, write the resulting policies as a comment in > > eglot.el. Consider also the change to Eglot's GitHub README.md which is > > where many people first take contact with Eglot. > > Sounds good, do you want me to CC you? Yes, but before you even start the discussion, come to a personal decision on how you want to deal with the above problems. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 13 Mar 2026 23:54:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 19:54:08 2026 Received: from localhost ([127.0.0.1]:49186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1CKT-00030S-7B for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 19:54:07 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57115) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1w1CKN-0002yD-74 for 80595 <at> debbugs.gnu.org; Fri, 13 Mar 2026 19:54:03 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 3D34D240101 for <80595 <at> debbugs.gnu.org>; Sat, 14 Mar 2026 00:53:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1773446032; bh=2kkN4p1ZdMblYK2PQemt8DiMUMjp4uFT8HAJ8ifoUmc=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=cWURfujdCnDBMIEX8IZTwGhVLZbSt+s9/t8bXRzVrUZs1FVs0XT+Uau1xu3NNqaVy gfSv8WBVutPYie7Gh8GjQpLGnAHaRCLJjU97M7PXvlosncKaeEJnstOz/1YPtwMIOr bJd8meH9XUvyblpBH1tuT375IMFsxaiAdMtgMnu2UZc1D9pE4XmlLIt6KSg5CsvSwL 5zK2HD1DbenJTdxJjP7s+gVvnwywWKMU4nDAIqQkYLR2F+zpi1XXYx1tNGTzpJwCWd aE1yjiLV1ry3GxQsqpXS3q0Go79GR5D1RyEXsN9PDmSV38Fq+wcgDB8J5G/zUW0xcG igOgJ4VrJ5/GA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fXhCM5Qgkz9rxL; Sat, 14 Mar 2026 00:53:51 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el In-Reply-To: <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> OpenPGP: id=philipk@HIDDEN; url="https://keys.openpgp.org/vks/v1/by-email/philipk@HIDDEN"; preference=signencrypt Date: Fri, 13 Mar 2026 23:53:51 +0000 Message-ID: <873423l20g.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > On Wed, Mar 11, 2026, 22:00 Philip Kaludercic <philipk@HIDDEN> wrote: > >> My plan would be to retain the current database for now, as fallbacks. = In >> a few years, when it has become convention for packages to declare the L= SP >> servers themselves, we can rethink the situation. >> > > I see. But that plan needs to be developed. It's not a question of years, > but rather when you plan to make upcoming Emacs 31 be the _oldest_ version > supported by Eglot. Right now Eglot supports 26.3 which is a bit dated, b= ut > 27 and 28 are still easily found in maintained GNU/Linux enterprise > distributions, for example. Yes, that was what I was trying to hand-wave at with "years". While it makes sense to have a more detailed plan on what to do when, I also don't think it is that urgent. It doesn't cost us anything to keep the database as is, but we can profit from the maintainers of major modes extending the database with more servers. > Therefore, if Emacs 31 is where you want this to happen you must imagine a > major version 3x happening where you _remove_ the eglot-server-programs > variable or at least its content. I suppose you would deprecate that > variable before doing that. Now in 31? In some 3y between 31 and 3x? In my current proposal we don't have to deprecate the eglot-server-programs variable. > And in all that time between Emacs 31 and 3x, what do you do when patches > come in asking for out-of-the box support for a new server/new major mode? > This is the most frequent change to Eglot. So what do you do? Reject it a= nd > suggest to put it into the mode (s)? Accept it into the deprecated > variable? Put it both in the deprecated variable and in the major mode? > What if that mode doesn't live in Emacs core or GNU ELPA?=20 What is the issue with pointing contributors to the major mode, wherever it might be maintained? That would have been my go-to answer, but you make it seem like there is something we are forgetting. > What if two qui= te > different modes from different vendors would benefit from the same server > invocation? Again, I don't understand the exact problem here. You have much more experience with these kinds of problems that I do, so perhaps it is obvious to you, but I don't see why both couldn't specify the same server invocation. > Consider the implications of each choice and discuss more broadly in > emacs-devel. Perhaps you or someone thinks it is acceptable for ELPA > versions of the package to have full LSP functionality but less > preconfigured servers, who knows? I certainly don't mind, but I think you > should hear others. In that case you would freeze the variable right now > have one less problem to worry about. > > Anyway, put a link to that discussion in the GitHub discussion forum. When > the discussion settles, write the resulting policies as a comment in > eglot.el. Consider also the change to Eglot's GitHub README.md which is > where many people first take contact with Eglot. Sounds good, do you want me to CC you? > The reason I went for the vector is that it shouldn't conflict with any >> other contact method declared until now, but perhaps we can also hard-co= de >> lists that begin with :alternatives to be handled specially? >> > > Right, I think something like that is better. Doesn't smell of syntax > bankruptcy as much. I think the hardest part will be to write an > intelligible docstring both in the source and in the manual. I'd start wi= th > that. Let me know when you have this patch for just the doc or the doc + > the new syntax handling. This part of the change can naturally proceed > independently from the other can of worms. Will do. > Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 11 Mar 2026 23:10:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 19:10:33 2026 Received: from localhost ([127.0.0.1]:55475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0ShD-0008TH-QM for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 19:10:33 -0400 Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]:55430) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w0Sh2-0008QA-ST for 80595 <at> debbugs.gnu.org; Wed, 11 Mar 2026 19:10:27 -0400 Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-467166cb638so203848b6e.2 for <80595 <at> debbugs.gnu.org>; Wed, 11 Mar 2026 16:10:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773270619; cv=none; d=google.com; s=arc-20240605; b=N6g4uJSEkgd3V/KQgM3RKKypf6l1oXEI0xZgqJ1JQtQgR/MMXFOUlX3+skHt5vpd+2 MbIPpfNBMQdta5I+OCI0GolF6p3REd9sFoxIDagKHEIfiRo2P28bz70OckneOifpUa+n rrqKnB/2YJ2YEYcJUqnoiiHeby84BDhy7uI4h6s03TfxQ1ENmyNTidhfAPEHWp89YIr7 oqPNZUbi3cM6qvnCJYhvvPdJdq4KLNdcPRVKLnmy9m9CzvaF/FB0tzNu5Rd6M1X789uN Z+2NbPi9wR1ylSXbMg5GYYAxT36ckFkyS6rBqgzULuLlZgVQJ0/SbS2Bz5JRC+fvV305 KXJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=H92cFXCarSh/ncjkdErv/LtqD3ckkTveyBYIjZVmR1w=; fh=b859ATIaHQbn1h2Zb2PkubzK/ZkVpYJnuwlYhXVatDA=; b=MGqxuYcB4lTG7LnVKVapJDtQUP4NzpROtsoIWI0yT0M4D/F2W95KT/5qo7LNDtS9u6 sUWVV3IVccu/qMXVjTF6DlSKAVAPr/ry1FUddpsEiFu9lSkxC0EiL8u5uGRl4GcrU/O/ dngv6EzoyL/Wdw+Newn2eEH50/XgNNk2voy4gAelC1gcwdPcPp/UWgje8+l0184kHHJP ueYZckdXRI7QLXenYg5bvz/BePaSU25SXGmSl8+ojZmY2DbVznD8yzRXWee8BW5HcGp8 r32JYoBDOgZdXh/T/i9RU0dlUMqg7w1X8z1A/gNqKwqXbJuCK9xGIMD1o1SVEIB6YP4G Ts+g==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773270619; x=1773875419; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H92cFXCarSh/ncjkdErv/LtqD3ckkTveyBYIjZVmR1w=; b=V96egPDBT9Qv95+HD9gFBCR6HoQuAuae1BRqxXqlstVN2n0nTx+yke6HHe65b7MHmG tmVMvTnFzIPM262emjdcGMJk+wvZe4MP6UMCSpGPBHpRCQ0gRz2KMQiE1cLs34x8JhVd CDrXkqMi9Pzb9pvq5yP1NEEs0sRcv7dyUONLb2cq1TGMc4VDAuoXQdaK9RczWw9bdzxZ z+M1TuYr/L0zTR872qZpwltMLHenPzNBwAJlw56zM2ix8loojwiW2DqNUPjoHSCo9hpu +N68VvyQjwi6V1MooPu/9zTTc33vIsVWYiLcFP5UhzSw0/H/8Vc40kLL3VbClPmDc50R 6XMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773270619; x=1773875419; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=H92cFXCarSh/ncjkdErv/LtqD3ckkTveyBYIjZVmR1w=; b=M5Wfp9U5EIOaHH1cMRnGOS2WkEzGUAHBjwsZzQRUC+QLp1alYPAo+5AH4n//RkfM6l 0552v0fYwmlKTZ6H9mPC3CUYFQPvEsqp/YKpCxoXYsENdSo5YaBA2lHqltz1PyLXepsP Q/cN+rUWkjtg1eZLedd9Xx8HedpDsV/1mg3mgm4u3KYA5Z2oh9LfvrdHpO5Dnu+LtOEx ZmThi42jWuLCYZt2etb4hyyggZl2g3l8z2NeZ10noODw1+NVVm3fxZkbBflHbNAiDHqk bKZi6XmBCQO/mA2WNgk45BXGX2yd4WsemCOEdd8t95es4o9U0SW9C4DumFgmzMFbM9kD UoUg== X-Gm-Message-State: AOJu0YxZu9VmDIb7QEhjLYbdsRMLLAvGyI7r1OxETFPl8YuOywocdYZl W/J7iZT8UVN6hcmz297MfaXJ7mLhUetDNp880suiMMFNDb9xvedPu8RtYF8Q16EBMsrCJOpUM+9 vZZmsK71l2xZxj83ovFeEigzpZEvuS9w= X-Gm-Gg: ATEYQzxEtY83xZ6t5Yjo2ujGbvt3Qz70Up+faEK4RG9MBCzHwn66BRY7yyfOGuOejC8 xc3OhFiAIi6SOrGS/X61LpYRdZWx6aFNc3NpGM+st1fj4UIbHpECpUAK1UHkedvyTxXOuVFCOOQ 1OJxNmChxw2+9jMxz5y+BV234zFHicNKY1Re37qEbPaoXKEqCGNkejWVJgUjJc/ZjRSsI26JheV HYeDo5snr6NWEn1oMH+dn0K8fFZsVtSxruX3scE+z7qQi9kMPGNVuID+r66c4gzpKrYvGLUegFp fMQjiPlvjmW5W3fm0kF/PsRPT0WaNdymbOoVccqwasbsVljiLjMsl1NUqkUm6V/llvk= X-Received: by 2002:a05:6808:bd1:b0:467:17a0:38c8 with SMTP id 5614622812f47-4673360fb35mr1976058b6e.50.1773270619535; Wed, 11 Mar 2026 16:10:19 -0700 (PDT) MIME-Version: 1.0 References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> In-Reply-To: <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Wed, 11 Mar 2026 23:10:10 +0000 X-Gm-Features: AaiRm50llkGiadbe9HtnvMFXB7SKCXiuJEJfeLDyCCoCV72TUf8edCMeJ5UwJQI Message-ID: <CALDnm50mspWpx9tL57V-pF_vW3V4QJPP4MAvG6BAnYg32yp1rw@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el To: Philip Kaludercic <philipk@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000005e3ed7064cc7bd53" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --0000000000005e3ed7064cc7bd53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 11, 2026, 22:00 Philip Kaludercic <philipk@HIDDEN> wrote: > My plan would be to retain the current database for now, as fallbacks. I= n > a few years, when it has become convention for packages to declare the LS= P > servers themselves, we can rethink the situation. > I see. But that plan needs to be developed. It's not a question of years, but rather when you plan to make upcoming Emacs 31 be the _oldest_ version supported by Eglot. Right now Eglot supports 26.3 which is a bit dated, but 27 and 28 are still easily found in maintained GNU/Linux enterprise distributions, for example. Therefore, if Emacs 31 is where you want this to happen you must imagine a major version 3x happening where you _remove_ the eglot-server-programs variable or at least its content. I suppose you would deprecate that variable before doing that. Now in 31? In some 3y between 31 and 3x? And in all that time between Emacs 31 and 3x, what do you do when patches come in asking for out-of-the box support for a new server/new major mode? This is the most frequent change to Eglot. So what do you do? Reject it and suggest to put it into the mode (s)? Accept it into the deprecated variable? Put it both in the deprecated variable and in the major mode? What if that mode doesn't live in Emacs core or GNU ELPA? What if two quite different modes from different vendors would benefit from the same server invocation? Consider the implications of each choice and discuss more broadly in emacs-devel. Perhaps you or someone thinks it is acceptable for ELPA versions of the package to have full LSP functionality but less preconfigured servers, who knows? I certainly don't mind, but I think you should hear others. In that case you would freeze the variable right now have one less problem to worry about. Anyway, put a link to that discussion in the GitHub discussion forum. When the discussion settles, write the resulting policies as a comment in eglot.el. Consider also the change to Eglot's GitHub README.md which is where many people first take contact with Eglot. The reason I went for the vector is that it shouldn't conflict with any > other contact method declared until now, but perhaps we can also hard-cod= e > lists that begin with :alternatives to be handled specially? > Right, I think something like that is better. Doesn't smell of syntax bankruptcy as much. I think the hardest part will be to write an intelligible docstring both in the source and in the manual. I'd start with that. Let me know when you have this patch for just the doc or the doc + the new syntax handling. This part of the change can naturally proceed independently from the other can of worms. Jo=C3=A3o --0000000000005e3ed7064cc7bd53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto"><br></div><div class=3D"gmail_quote gma= il_quote_container" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On W= ed, Mar 11, 2026, 22:00 Philip Kaludercic <<a href=3D"mailto:philipk@pos= teo.net">philipk@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">My plan would be to retain the current database = for now, as fallbacks.=C2=A0 In a few years, when it has become convention = for packages to declare the LSP servers themselves, we can rethink the situ= ation.<br></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">= I see. But that plan needs to be developed. It's not a question of year= s, but rather when you plan to make upcoming Emacs 31 be the _oldest_ versi= on supported by Eglot. Right now Eglot supports 26.3 which is a bit dated, = but 27 and 28 are still easily found in maintained GNU/Linux enterprise dis= tributions, for example.</div><div dir=3D"auto"><br></div><div dir=3D"auto"= >Therefore, if Emacs 31 is where you want this to happen you must imagine a= major version 3x happening where you _remove_ the eglot-server-programs va= riable or at least its content. I suppose you would deprecate that variable= before doing that. Now in 31? In some 3y between 31 and=C2=A0 3x?=C2=A0</d= iv><div dir=3D"auto"><br></div><div dir=3D"auto">And in all that time betwe= en Emacs 31 and 3x, what do you do when patches come in asking for out-of-t= he box support for a new server/new major mode? This is the most frequent c= hange to Eglot. So what do you do? Reject it and suggest to put it into the= mode (s)? Accept it into the deprecated variable? Put it both in the depre= cated variable and in the major mode? What if that mode doesn't live in= Emacs core or GNU ELPA? What if two quite different modes from different v= endors would benefit from the same server invocation?</div><div dir=3D"auto= "><br></div><div dir=3D"auto">Consider the implications of each choice and = discuss more broadly in emacs-devel. Perhaps you or someone thinks it is ac= ceptable for ELPA versions of the package to have full LSP functionality bu= t less preconfigured servers, who knows?=C2=A0 I certainly don't mind, = but I think you should hear others.=C2=A0 In that case you would freeze the= variable right now have one less problem to worry about.</div><div dir=3D"= auto"><br></div><div dir=3D"auto">Anyway, put a link to that discussion in = the GitHub discussion forum. When the discussion settles, write the resulti= ng policies as a comment in eglot.el. Consider also the change to Eglot'= ;s GitHub README.md which is where many people first take contact with Eglo= t.</div><div dir=3D"auto"><br></div><div class=3D"gmail_quote gmail_quote_c= ontainer" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The reason I went for the vector is that it shouldn't conflict with any= other contact method declared until now, but perhaps we can also hard-code= lists that begin with :alternatives to be handled specially?<br></blockquo= te></div><div dir=3D"auto"><br></div><div dir=3D"auto">Right, I think somet= hing like that is better. Doesn't smell of syntax bankruptcy as much. I= think the hardest part will be to write an intelligible docstring both in = the source and in the manual. I'd start with that. Let me know when you= have this patch for just the doc or the doc + the new syntax handling. Thi= s part of the change can naturally proceed independently from the other can= of worms.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o=C2= =A0</div></div> --0000000000005e3ed7064cc7bd53--
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 11 Mar 2026 22:00:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 18:00:36 2026 Received: from localhost ([127.0.0.1]:54843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0RbX-0007g9-IM for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 18:00:36 -0400 Received: from mout02.posteo.de ([185.67.36.66]:47161) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1w0RbT-0007dy-U4 for 80595 <at> debbugs.gnu.org; Wed, 11 Mar 2026 18:00:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7E5FB240103 for <80595 <at> debbugs.gnu.org>; Wed, 11 Mar 2026 23:00:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1773266425; bh=Dv64Ovs5le7vPB69BQeseCc2IPG1gw3yI9LunUJm64I=; h=Date:From:To:CC:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=ekmhQBG8Ao0xw6dnrDP+lCbGwhkhN3uQNLxDbZ+NXGZ14DX1YIn2h2edzIsxOD8hb E/z32WhHJo+xHGdahWGXRnXtzPkx1fO8q0dak9B5BgimKSzwZDv2z9aJCyhR09MUr7 xttpDrZ6ut0gueNdiQuf9le1PKPJFXM+FPpFG0OxZj8fKhKF5kV7QBZ6qU8XK0bEgi IysvzSVmOhXpLwSbCtppGf7v1v90JEX2bKCDQECyXmrUms5XQod1SuxVCml5aT/Q6c PczUXYScZXeqWN/fm/Qx3hfZSsk6k7XT1p479J34r0twj6GeV3DmL3+ZfGHVZVmklH SB2ICBd23kEmg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fWPnN2Hwvz9rxG; Wed, 11 Mar 2026 23:00:24 +0100 (CET) Date: Wed, 11 Mar 2026 22:00:25 +0000 From: Philip Kaludercic <philipk@HIDDEN> To: =?ISO-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2380595=3A_=5BPATCH=5D_Prepare_infrastru?= =?US-ASCII?Q?cture_to_move_LSP_servers_out_of_eglot=2Eel?= In-Reply-To: <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> References: <878qbym7rn.fsf@HIDDEN> <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> Message-ID: <202EDA28-2B22-4CFF-AA32-01876DD5C0E0@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) My plan would be to retain the current database for now, as fallbacks=2E I= n a few years, when it has become convention for packages to declare the LS= P servers themselves, we can rethink the situation=2E The reason I went for the vector is that it shouldn't conflict with any ot= her contact method declared until now, but perhaps we can also hard-code li= sts that begin with :alternatives to be handled specially? On 11 March 2026 22:53:54 CET, "Jo=C3=A3o T=C3=A1vora" <joaotavora@gmail= =2Ecom> wrote: >How do you plan to have Eglot, the :core ELPA package, stay functional in >older Emacsen? > >The move away from eglot-alternatives the function to some declarative >:alternatives syntax sounds good=2E However I'm not sure the vector is th= e >right approach=2E It might be=2E > >Jo=C3=A3o T=C3=A1vora > >On Wed, Mar 11, 2026, 20:28 Philip Kaludercic <philipk@posteo=2Enet> wrot= e: > >> Tags: patch >> >> >> As was previously discussed, we would like to move the declarations of >> what LSP servers to use per major mode out of Eglot=2E I'd like to pus= h >> this initiative forward with something actionable to discuss: The patch >> below implements a suggestion I had made once before, that would allow >> external packages to configure `eglot-server-programs' without loading >> eglot=2Eel and without having to worry if it has been loaded or not=2E >> >> As a reminder: The main problem here is that if there are multiple LSP >> servers to choose from, the current solution is to generate a contact >> method by calling `eglot-alternatives' that returns a closure=2E This >> means that eglot would have to be loaded for this to work=2E Instead, = I >> suggest interpreting >> >> [:alternatives CONTACTS=2E=2E=2E] >> >> as notation for >> >> (eglot-alternatives '(CONTACTS=2E=2E=2E)) >> >> which Eglot translates as needed=2E >> >> Adding :alternatives at the beginning of the vector is entirely >> optional, I was thinking that we might want to extend the vector >> notation could be useful for some other feature in the future=2E >> >> Furthermore, the patch moves the LSP server list out to a constant, and >> uses that to populate `eglot-server-programs' when loading eglot=2Eel, = so >> that external packages can extend `eglot-server-programs' before >> eglot=2Eel was loaded=2E >> >> After we apply something like this, I can then proceed to contact the >> maintainers of external packages and suggest moving the LSP >> configuration to their packages=2E >> >> In GNU Emacs 31=2E0=2E50 (build 4, x86_64-pc-linux-gnu, GTK+ Version >> 3=2E24=2E49, cairo version 1=2E18=2E4) of 2026-03-10 built on siskin >> Repository revision: 41746d5fb2f9979b533cf774cbd967ff39cc8672 >> Repository branch: master >> System Description: Debian GNU/Linux 13 (trixie) >> >> Configured using: >> 'configure --with-pgtk' >> >>
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.Received: (at 80595) by debbugs.gnu.org; 11 Mar 2026 21:54:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 17:54:10 2026 Received: from localhost ([127.0.0.1]:54742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0RVJ-0006fJ-6e for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 17:54:10 -0400 Received: from mail-oi1-x22b.google.com ([2607:f8b0:4864:20::22b]:43096) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w0RVG-0006ek-87 for 80595 <at> debbugs.gnu.org; Wed, 11 Mar 2026 17:54:07 -0400 Received: by mail-oi1-x22b.google.com with SMTP id 5614622812f47-46701f2077cso1256781b6e.0 for <80595 <at> debbugs.gnu.org>; Wed, 11 Mar 2026 14:54:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773266044; cv=none; d=google.com; s=arc-20240605; b=jQbZhLlI5c/XkunNBLoO1Hxk7wixaiw1Z9nNTQp6qeDzIx+BMh50+EUGf149ItTEK5 FM5EgDNqqDUZCyWILrvZGnsS0TpEpVfErnKy8PONG028NLDRdHDdblUPee5c8QhcmwA8 VDGJ5tHbGbTaSaNzyZ8SephkjO10eSE4CMcdth84VN5zQzov7ynLxVhGu8xpEJOgO65z bTj3us+7eVssp4XfkhFSkdJPoD3xvvjvhs/d3OBOKanVho6YDVeyyEObdTjuQJChRt6n YYdHcvNGCMo1lR/hEPcwiJcp3qu2SfA80x/6qmtcLKyvu7+IVxXU7PIN17XF7FJII3PU dREA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gG88RQ/PKhY8X56RxO1bQ4+deEdM8Z2CA6jFdJb4dGQ=; fh=b859ATIaHQbn1h2Zb2PkubzK/ZkVpYJnuwlYhXVatDA=; b=ReQAwTi0VUPeHwc6eQu8MSs1AZhozhS4iojfBG+rbSxaHYMZJk8b5tfbUgyjW4PCNl rrDYNakgBGktydB7n8xUlHU0+ZixHTNHL157HZi8gXSvYf+nctA6uf4Gpr4juJTkwGhw IZbFjHlFybXMzC1MJnNC2zUEr1QwxzL2JucVGok3sZQyWmB8xomGDfbM9/nyKr68xFKx h+QtDG39btMAIXzAlIv5jg5Y1KXsKRjbR5OC40aFX7EAlHcEw56dC4A6lBq37M7UBx0/ N9wKB1J46CdC9QzfG3/yGGkgCNwA/CSdYoRMYUbPjlW9vyyrQEtCty6O85R99Y+E+Xh2 67eg==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773266044; x=1773870844; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gG88RQ/PKhY8X56RxO1bQ4+deEdM8Z2CA6jFdJb4dGQ=; b=m3ZhrA6TJ45AbDQIsweQMITUWpWghImYyUg1nCtT8GHEIL5PF1T0WTxDTrEezuldar w2zWgKs9KFMx2bsDFZgtcJDAOTlOnSvkG+ShaDt4EVS5qlIjElA+k8IPD5qkVvvO7yhY 26P3kE6s2QKiMx8pTuDhadGuU/UzhprDCltgT7Lh6JSE7hXHN3fUneH21gY4112NX2gx pL4HLwT2oT0ctvPdOohQmxmMbqIS0c+YkKqLLmsrJLOImOGaPvuVtD563DhUlClbxaTA NDUkaXP9MDEiVd3DNLnCiI5lG4JK+hIsb85W6qxNMORQSjmuzUKgfzFKAVYjAuUWOuun uzng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773266044; x=1773870844; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gG88RQ/PKhY8X56RxO1bQ4+deEdM8Z2CA6jFdJb4dGQ=; b=e8/W4KxxR2H1oGS6tiOYCvxPygmeq6afPE7c1lsrGVJKwxiJjsyb4mO3rUNz4uwPdi ixGNCjG3X3eXj/GcpGpCUGPOs6p73WcRm9uQEEl03gM2CD2WfpaybZoZ0WiztuKphGFY VvyP00sx5rucK1NU5gVM0VrDOED3alSpb/dU2F6Jps/G9xDl/29NIfgV6Nh6xuPlyXBY YEgUwm86YmqLDlyzMfJy5RqYb3EoYYMINDVs0XAOD/LVY+6NSqrF3Tdj1y5BbMya5zth HxxMq1ifRl9TWIQ0ZZTSKbX0JKQciDGItGRroINhu2zvpVmPax7EBepmAWEJhcdFVkrj momA== X-Gm-Message-State: AOJu0YzDIogsU3eb2WCGULCBrGiXWOng6A5Bgmna0lzZKrP1CMAjULRw davnBPgw9aXyE/2VcHTBJ4wxMQaN3Cvt54JncetGKfcz+PrG7+hC+pa3PjPRp8qPVenL6zAZu7q RF2rI/55myRIQQ/93Rui/28MeeUUDZX4= X-Gm-Gg: ATEYQzwW370k7VVJ7K7q10AqlarIjyyvuDaTXPtQT+936sB3a4qlilA+BKHh2M2eL/Z OcAOCqcpB8A13znhzrgiLs8c1m5crsGACG4AA8I71OiNd/g3Jub6Ch9jg+W8fq5/5cOJR4ma/TA 38uWiB6JxR1X/tbihjaaYGfrSUGGAUg9tGSU7s5xQo04lf6L3TX7o1pDsIaEXfuZeHiUMYMBhni 0HPVeepdKb2WvgHkLVDwGhJvbTcI+3rf2r3VQEmK+6enr/M+jvWqTjUMUcVNuUFvdX7TppntKXn ImBWw5AnPqHFeN7s6MfXOrXaIZWE3aaY3ah1EMulp3SB+/a1C1/dGwPY9r5fEXhQJ9Y= X-Received: by 2002:a05:6820:2296:b0:67b:b926:2329 with SMTP id 006d021491bc7-67bd0713165mr636989eaf.12.1773266044139; Wed, 11 Mar 2026 14:54:04 -0700 (PDT) MIME-Version: 1.0 References: <878qbym7rn.fsf@HIDDEN> In-Reply-To: <878qbym7rn.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Wed, 11 Mar 2026 21:53:54 +0000 X-Gm-Features: AaiRm53DnXkcS5EH4at6BFBCb64l2x2H3ZJmC41Gpy-JQQ0EiNoLr_bd04BJn34 Message-ID: <CALDnm518C+mfY09t4qqXddyf+UDjz7g3u8Z+K6prcei1No1FNA@HIDDEN> Subject: Re: bug#80595: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el To: Philip Kaludercic <philipk@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000a73bfd064cc6acf5" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80595 Cc: 80595 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --000000000000a73bfd064cc6acf5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How do you plan to have Eglot, the :core ELPA package, stay functional in older Emacsen? The move away from eglot-alternatives the function to some declarative :alternatives syntax sounds good. However I'm not sure the vector is the right approach. It might be. Jo=C3=A3o T=C3=A1vora On Wed, Mar 11, 2026, 20:28 Philip Kaludercic <philipk@HIDDEN> wrote: > Tags: patch > > > As was previously discussed, we would like to move the declarations of > what LSP servers to use per major mode out of Eglot. I'd like to push > this initiative forward with something actionable to discuss: The patch > below implements a suggestion I had made once before, that would allow > external packages to configure `eglot-server-programs' without loading > eglot.el and without having to worry if it has been loaded or not. > > As a reminder: The main problem here is that if there are multiple LSP > servers to choose from, the current solution is to generate a contact > method by calling `eglot-alternatives' that returns a closure. This > means that eglot would have to be loaded for this to work. Instead, I > suggest interpreting > > [:alternatives CONTACTS...] > > as notation for > > (eglot-alternatives '(CONTACTS...)) > > which Eglot translates as needed. > > Adding :alternatives at the beginning of the vector is entirely > optional, I was thinking that we might want to extend the vector > notation could be useful for some other feature in the future. > > Furthermore, the patch moves the LSP server list out to a constant, and > uses that to populate `eglot-server-programs' when loading eglot.el, so > that external packages can extend `eglot-server-programs' before > eglot.el was loaded. > > After we apply something like this, I can then proceed to contact the > maintainers of external packages and suggest moving the LSP > configuration to their packages. > > In GNU Emacs 31.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version > 3.24.49, cairo version 1.18.4) of 2026-03-10 built on siskin > Repository revision: 41746d5fb2f9979b533cf774cbd967ff39cc8672 > Repository branch: master > System Description: Debian GNU/Linux 13 (trixie) > > Configured using: > 'configure --with-pgtk' > > --000000000000a73bfd064cc6acf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>How do you plan to have Eglot, the :core ELPA packag= e, stay functional in older Emacsen?</div><div dir=3D"auto"><br></div><div = dir=3D"auto">The move away from eglot-alternatives the function to some dec= larative :alternatives syntax sounds good. However I'm not sure the vec= tor is the right approach. It might be.</div><div dir=3D"auto"><br></div><d= iv data-smartmail=3D"gmail_signature">Jo=C3=A3o T=C3=A1vora</div></div><br>= <div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"= gmail_attr">On Wed, Mar 11, 2026, 20:28 Philip Kaludercic <<a href=3D"ma= ilto:philipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br></div><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p= x solid rgb(204,204,204);padding-left:1ex">Tags: patch<br> <br> <br> As was previously discussed, we would like to move the declarations of<br> what LSP servers to use per major mode out of Eglot.=C2=A0 I'd like to = push<br> this initiative forward with something actionable to discuss: The patch<br> below implements a suggestion I had made once before, that would allow<br> external packages to configure `eglot-server-programs' without loading<= br> eglot.el and without having to worry if it has been loaded or not.<br> <br> As a reminder: The main problem here is that if there are multiple LSP<br> servers to choose from, the current solution is to generate a contact<br> method by calling `eglot-alternatives' that returns a closure.=C2=A0 Th= is<br> means that eglot would have to be loaded for this to work.=C2=A0 Instead, I= <br> suggest interpreting<br> <br> =C2=A0 [:alternatives CONTACTS...]<br> <br> as notation for <br> <br> =C2=A0 (eglot-alternatives '(CONTACTS...))<br> <br> which Eglot translates as needed.<br> <br> Adding :alternatives at the beginning of the vector is entirely<br> optional, I was thinking that we might want to extend the vector<br> notation could be useful for some other feature in the future.<br> <br> Furthermore, the patch moves the LSP server list out to a constant, and<br> uses that to populate `eglot-server-programs' when loading eglot.el, so= <br> that external packages can extend `eglot-server-programs' before<br> eglot.el was loaded.<br> <br> After we apply something like this, I can then proceed to contact the<br> maintainers of external packages and suggest moving the LSP<br> configuration to their packages.<br> <br> In GNU Emacs 31.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version<br> =C2=A03.24.49, cairo version 1.18.4) of 2026-03-10 built on siskin<br> Repository revision: 41746d5fb2f9979b533cf774cbd967ff39cc8672<br> Repository branch: master<br> System Description: Debian GNU/Linux 13 (trixie)<br> <br> Configured using:<br> =C2=A0'configure --with-pgtk'<br> <br> </blockquote></div> --000000000000a73bfd064cc6acf5--
bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 11 Mar 2026 20:27:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 16:27:39 2026
Received: from localhost ([127.0.0.1]:53878 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w0Q9b-0003Zf-51
for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 16:27:39 -0400
Received: from lists.gnu.org ([2001:470:142::17]:35732)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <philipk@HIDDEN>)
id 1w0Q9Y-0003Yk-EM
for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 16:27:37 -0400
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 <philipk@HIDDEN>)
id 1w0Q9T-0004Wz-3u
for bug-gnu-emacs@HIDDEN; Wed, 11 Mar 2026 16:27:31 -0400
Received: from mout01.posteo.de ([185.67.36.65])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <philipk@HIDDEN>)
id 1w0Q9Q-0007zo-Jr
for bug-gnu-emacs@HIDDEN; Wed, 11 Mar 2026 16:27:30 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 0BEC5240027
for <bug-gnu-emacs@HIDDEN>; Wed, 11 Mar 2026 21:27:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017;
t=1773260846; bh=6trLZt7kRkiWEa+mZfc2osKkcpnFdYwBm/eFhpuj720=;
h=From:To:Subject:OpenPGP:Date:Message-ID:MIME-Version:Content-Type:
From;
b=gD8J786WdqXnTFw4mBijtKLv2vyYMk0o9sAnmgrrt4r7DmEQzOZ1sxqHdJsM3ncE+
nqsJveY+vkYzmMxVAGSZimQG5Fd2bPQZH2xNL49dJX3Tq7XBpooVqevQtGcaNWfRDf
KIZWA+tup3GP9AGTesJQpyks0MwDzq7vx32NOnS+E4304jwQc09LIDeBeMWDSByfJ3
P7UHS82qkLYh/P2vKDYUwY8SPZaBdIrULfFT7VwS6xrMpNieeGh925ciwgdqa25SRK
Oyo9aH1fDINLDSuFCqyGdsvzpw9fT3y4/YtAWCG7KVmv20HuHwvf/hguFMwhRv+V2f
/40uJp2zDXe/w==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4fWMk52qJzz9rxD
for <bug-gnu-emacs@HIDDEN>; Wed, 11 Mar 2026 21:27:25 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el
X-Debbugs-Cc: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
OpenPGP: id=philipk@HIDDEN;
url="https://keys.openpgp.org/vks/v1/by-email/philipk@HIDDEN";
preference=signencrypt
Date: Wed, 11 Mar 2026 20:27:25 +0000
Message-ID: <878qbym7rn.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@HIDDEN;
helo=mout01.posteo.de
X-Spam_score_int: -26
X-Spam_score: -2.7
X-Spam_bar: --
X-Spam_report: (-2.7 / 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_MED=-2.3, RCVD_IN_MSPIKE_H2=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.819, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.903,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--=-=-=
Content-Type: text/plain
Tags: patch
As was previously discussed, we would like to move the declarations of
what LSP servers to use per major mode out of Eglot. I'd like to push
this initiative forward with something actionable to discuss: The patch
below implements a suggestion I had made once before, that would allow
external packages to configure `eglot-server-programs' without loading
eglot.el and without having to worry if it has been loaded or not.
As a reminder: The main problem here is that if there are multiple LSP
servers to choose from, the current solution is to generate a contact
method by calling `eglot-alternatives' that returns a closure. This
means that eglot would have to be loaded for this to work. Instead, I
suggest interpreting
[:alternatives CONTACTS...]
as notation for
(eglot-alternatives '(CONTACTS...))
which Eglot translates as needed.
Adding :alternatives at the beginning of the vector is entirely
optional, I was thinking that we might want to extend the vector
notation could be useful for some other feature in the future.
Furthermore, the patch moves the LSP server list out to a constant, and
uses that to populate `eglot-server-programs' when loading eglot.el, so
that external packages can extend `eglot-server-programs' before
eglot.el was loaded.
After we apply something like this, I can then proceed to contact the
maintainers of external packages and suggest moving the LSP
configuration to their packages.
In GNU Emacs 31.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
3.24.49, cairo version 1.18.4) of 2026-03-10 built on siskin
Repository revision: 41746d5fb2f9979b533cf774cbd967ff39cc8672
Repository branch: master
System Description: Debian GNU/Linux 13 (trixie)
Configured using:
'configure --with-pgtk'
--=-=-=
Content-Type: text/x-patch; charset=utf-8
Content-Disposition: attachment;
filename=0001-Prepare-infrastructure-to-move-LSP-servers-out-of-eg.patch
Content-Transfer-Encoding: quoted-printable
From 6ec0433efd482c4492e90d5b08c3d86bfac3e7a7 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@HIDDEN>
Date: Wed, 11 Mar 2026 20:06:48 +0100
Subject: [PATCH] Prepare infrastructure to move LSP servers out of eglot.el
* doc/misc/eglot.texi (Setting Up LSP Servers): Document the
[:alternatives ...] syntax for 'eglot-server-programs'.
* lisp/progmodes/eglot.el (eglot-server-programs-defaults): Move
definitions from 'eglot-server-programs' to here.
(eglot-server-programs): Set default value to nil, and populate
it using the values from 'eglot-server-programs-defaults' when
loading Eglot.
(eglot--lookup-mode): Add [:alternatives ...] syntax as an
alternative to 'eglot-alternatives' that doesn't require loading
Eglot.
---
doc/misc/eglot.texi | 11 +++++++++++
lisp/progmodes/eglot.el | 28 +++++++++++++++++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/doc/misc/eglot.texi b/doc/misc/eglot.texi
index 68829a733c5..1b4f485d394 100644
--- a/doc/misc/eglot.texi
+++ b/doc/misc/eglot.texi
@@ -257,6 +257,11 @@ Setting Up LSP Servers
for determining the program to start and its command-line arguments.
@end table
=20
+@item [:alternatives @var{alternatives}...]
+Sometimes, multiple servers are acceptable alternatives for handling a
+given major-mode. In those cases, you may list any of the above in
+@var{alternatives} and have Eglot check each for availability.
+
@end defvar
=20
Eglot comes with a fairly complete set of associations of major-modes to
@@ -294,6 +299,12 @@ Setting Up LSP Servers
("phewls" "--fast"))))))
@end lisp
=20
+Using @code{eglot-alternatives} is equivalent to the
+@code{[:alternatives @var{alternatives}...]} mentioned above. The
+advantage of the latter is that you can use it without having to load
+Eglot, which is interesting if you are extending
+@code{eglot-server-programs} for a major mode from a package.
+
If you have @command{fools} and @command{phewls} installed, the function
produced by @code{eglot-alternatives} will prompt for the server to use
in @code{foo-mode} buffers. Else it will use whichever is available.
diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index a4f076a6197..2641da5232c 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -235,10 +235,7 @@ eglot-alternatives
when probe return (cons probe args)
finally (funcall err)))))))
=20
-(defvar eglot-server-programs
- ;; FIXME: Maybe this info should be distributed into the major modes
- ;; themselves where they could set a buffer-local `eglot-server-program'
- ;; which would allow deprecating this database.
+(defconst eglot-server-programs-defaults
;; FIXME: With `derived-mode-add-parents' in Emacs=E2=89=A530, some of
;; those entries can be simplified, but we keep them for when
;; `eglot.el' is installed via GNU ELPA in an older Emacs.
@@ -353,7 +350,9 @@ eglot-server-programs
. ,(lambda (_interactive project)
(list "millet-ls" (project-root project))))
((blueprint-mode blueprint-ts-mode) . ("blueprint-compiler" "lsp"))
- ((odin-mode odin-ts-mode) . ("ols")))
+ ((odin-mode odin-ts-mode) . ("ols"))))
+
+(defvar eglot-server-programs nil
"How the command `eglot' guesses the server to start.
An association list of (MAJOR-MODE . CONTACT) pairs. MAJOR-MODE
identifies the buffers that are to be managed by a specific
@@ -419,7 +418,19 @@ eglot-server-programs
can't produce a valid CONTACT. The helper function
`eglot-alternatives' (which see) can be used to produce a
function that offers more than one server for a given
- MAJOR-MODE.")
+ MAJOR-MODE.
+
+* A vector [:alternatives CONTACTS...] is equivalent to invoking
+ `eglot-alternatives' with CONTACTS. Use this if extending
+ `eglot-server-programs' from an external package, without having to
+ introduce a strong dependency on Eglot or having to load it.")
+
+;; We populate the list when loading so that we don't overwrite any
+;; previous entries that might have been added for major modes before
+;; Eglot was loaded. We add all entries using `add-to-list' to avoid
+;; duplicating entries if loading this file multiple times.
+(dolist (ent eglot-server-programs-defaults)
+ (add-to-list 'eglot-server-programs ent t))
=20
(defface eglot-highlight-symbol-face
'((t (:inherit bold)))
@@ -1495,7 +1506,10 @@ eglot--lookup-mode
when (cl-some (lambda (cell)
(provided-mode-derived-p mode (car cell)))
normalized)
- return (cons normalized contact)
+ return (cons normalized (if (and (vectorp contact)
+ (eq (aref contact 0) :alternatives))
+ (eglot-alternatives (cdr (cl-coerce contact=
'list)))
+ contact))
;; If lookup fails at least return some suitable LANGUAGES.
finally (cl-return
(cons (list (funcall lang-from-sym major-mode))
--=20
2.47.3
--=-=-=--
Philip Kaludercic <philipk@HIDDEN>:joaotavora@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.joaotavora@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80595; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.