From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Making `eglot-server-programs' a custom variable? Date: Fri, 11 Nov 2022 00:59:03 +1100 Message-ID: <86tu36dfuq.fsf@gmail.com> References: <86fservpri.fsf@gnu.org> <831qqbtixr.fsf@gnu.org> <865yfndy14.fsf@gmail.com> <83o7tfrzcy.fsf@gnu.org> <861qqbdtv2.fsf@gmail.com> <83y1sjqcu4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16935"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.1; emacs 29.0.50 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 10 15:50:56 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ot8tM-0004ER-1n for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Nov 2022 15:50:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ot8sX-0007WG-FV; Thu, 10 Nov 2022 09:50:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ot8sH-0007Ud-17 for emacs-devel@gnu.org; Thu, 10 Nov 2022 09:49:52 -0500 Original-Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ot8s7-0000Lg-Ft; Thu, 10 Nov 2022 09:49:41 -0500 Original-Received: by mail-pf1-x430.google.com with SMTP id 130so2345744pfu.8; Thu, 10 Nov 2022 06:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=vWmYdrqrgTRH5QevL2isYVIjW3wjtsytI1iWS18ghAM=; b=CY+cP3NwPnvt9YvUmO5n+lM6cC/ZnisvX6QgI9suw9IjWKv91BKnjZtdEAPrvpFKqd mR6x39OMvp3pDYmIY94xCbImxXMZxzpszZPA3sXf6wxhYse2EIcQDxqnmGmDZX8mAEXi rPqKvKIyDqvJAJoo+kIcRJgR/4hHp0rW6jAvXcS2p0O4u+0hwDqbgPFVXlIxFl6CfJTz kNoBpYOAJVUjyfnnT6idpeAAEDZYRK0NIat9znUmE3vQf+ydG+Px2DHgK3B+PBWeWMEJ S7CTyTKelHAvNW5YMcRUACAzmFxwSf8AaMgItk7NbICP8CTqRNpdVWA8LBApAgjeuYK2 BDQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vWmYdrqrgTRH5QevL2isYVIjW3wjtsytI1iWS18ghAM=; b=aJfGsQR21cdCO/fDRvf/8tLU6s7+dog9PWaH1OaOSsxsppC9oGpmJWT2kbas/PSlnb 8uYoaw40KRZvVdpLsF5gq0jf3gGlDEEdSqE6OE3LOvYUFPBIu1mde60tBnYHh3O/c76Q TNRLGyC5bMgCuYFKfxBUwPUb+plLKgJ3rGHSotQJACRt//q50Qhyp9B7i5CdxlnIhrWp HFt6jaNFWsEdx04EvKcfp/OYfMbQLeGnKDwxFpOtIhsfNHPVHUiX4C76gOsTu5FAz9HK +PDRzZsWUxoi4UMoR1i9XL++67o/6Hdb8i/iqTnOgSelbxESVK9a/v5TJ4UeT6Ubqy82 tCsQ== X-Gm-Message-State: ACrzQf3/2veVkkWY7+7f894WmSENX17FJGDIOsjNiofvxQIENVnMknoJ JbW0B5Fy+NkS2tQ/wFVdb2wIaQUrAHw= X-Google-Smtp-Source: AMsMyM7sjturUNNOca8xRpxpCyvsCGAWBheeQ3j/bOhozl5dEVw0DFP7r0ilFpJA784KTzup+ahSgg== X-Received: by 2002:a63:90c7:0:b0:46e:c7be:16e1 with SMTP id a190-20020a6390c7000000b0046ec7be16e1mr56883543pge.296.1668091777100; Thu, 10 Nov 2022 06:49:37 -0800 (PST) Original-Received: from dingbat (220-235-181-183.dyn.iinet.net.au. [220.235.181.183]) by smtp.gmail.com with ESMTPSA id ne9-20020a17090b374900b00213a9e1ec44sm3154564pjb.52.2022.11.10.06.49.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 06:49:36 -0800 (PST) In-reply-to: <83y1sjqcu4.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::430; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x430.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299490 Archived-At: Eli Zaretskii writes: >> From: Tim Cross >> Cc: emacs-devel@gnu.org >> Date: Thu, 10 Nov 2022 20:34:49 +1100 >> >> >> I'm not sure that intent will hold. It has the underlying assumption >> >> there is a definitive language server for each language. >> > >> > No, it doesn't. Please see the current value of the variable and its >> > documentation in the manual. >> >> I guess you will have to explain as I've looked at the documentation >> again and still don't see how you can have two different language >> servers for the same language. While you can have multiple entries for >> the same language modes, only the first one in the list take effect. > > That's not my understanding. > >> >> There are multiple servers for many languages and individual >> >> preferences/requirements can differ. >> > >> > Yes, and the variable already supports that. >> > >> >> How? > > Via eglot-alternatives. There are entries in the value which already > use that. And the change you suggested used that as well. So I > wonder what kind of misunderstanding are we having here. > That function is not mentioned or referenced in the documentation for eglot-server-programs. I did see that function when I was configuring eglot, but it wasn't at all clear to me how it fitted into the picture. I cold not find any reference to eglot-alternatives in the eglot manual and it isn't listed in the index, so after you mentioning it, while I *think* I understand what it does, I still don't see how it is relevant in this situation (unless you use it in conjunction with other elisp to implement a new command for selecting which server to use?). Not sure how you feel it was part of the change I suggested given I've not suggested any change - all I did was copy and paste the configuration I had to add in order to get eglot to work with my preferred language server for javascript. I really added it to show that adding a new/different server isn't always straight-forward and that it requires editing that eglot-server-programs variable. >> Please show as it isn't clear to me from the documentation and >> there isn't a single entry which shows support for multiple language >> servers for the same language (where only one is active at a time of course). . > > You mean, there's a difference between several servers for the same > mode and several servers for the same language? What is the > difference? Or is that also part of the misunderstanding? I don't think 'mode' adds much here. It is really just an emacs specific notion which langauge servers know nothing about and used to identify the source language. For example, we have js-mode and typescript-mode, both modes for editing/developing javascript. However, there is more than one language server mode for javascript. The 'default' is typescript-language-server, my preference is deno. Both are language servers for javascript and typescript. Different language servers for the same language can offer different features or different strategies in supporting a feature. One server might have different snippets, different lint rules, different formatting rules or use a different strategy for implementing things like code completion or simply have a different performance profile. As it stands now, you have an alist with keys that are emacs mode names and values which are the language server to run (along with command line arguments etc) when you use eglot in one of the modes used as the key. I cannot see how you can have two separate entries for (js-mode typescript-mode) or if you do, how the user indicates which entry to use. In my case, my configuration of deno works because it appears in the list before the default entry which uses typescript-language-server. Your suggestion was that if there is a server not in the list, it should just be added to the list. I still don't see how this would work in the general case. If there are two entries in the list with the same key, how does the user identify which entry they want to be used? It was this which made be suggest that your suggestion that this variable would typically not need to be modified by end users may not hold. I think it will be something which users will often need to do - especially as this space is still evolving and the status of servers for many languages are still somewhat in flux. Note that I may not agree 100% with the OPs position that the manual should be updated. When adding code to your init.el file, cut and paste examples frequently get people into more trouble than help. I think that if your going to add calls to add-to-list in your init.el file, you relaly should understand what that means and why you cannot add to a list which doesn't yet exist etc. However, I disagree with the suggestion this variable is some internal variable which won't need to be modified by users. I also wanted to highlight that in this specific case of adding deno as a server, it was much easier and more straight-forward to do so with lsp-mode than it was in eglot. This is not a suggestion that lsp-mode is better - for many reasons, I very much prefer the architecture and design goals of eglot over lsp-mode. It was mentioned as just a data point from someone who has used both. Note also that I did initially try adding deno useing the simple/naive approach as outlined in the manual, but could not get that to work. In the end, I got it working after some help from IRC.