From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Making `eglot-server-programs' a custom variable? Date: Thu, 10 Nov 2022 08:57:09 -0500 Message-ID: References: <86fservpri.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="37030"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Arash Esbati , Eli Zaretskii , Tim Cross , emacs-devel To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 10 15:07:33 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 1ot8DM-0009KI-DC for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Nov 2022 15:07:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ot8Cc-0000uC-1L; Thu, 10 Nov 2022 09:06:46 -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 1ot8CW-0000sq-SD for emacs-devel@gnu.org; Thu, 10 Nov 2022 09:06:42 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ot8CV-0003tq-AI; Thu, 10 Nov 2022 09:06:40 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6F83280073; Thu, 10 Nov 2022 08:57:18 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DDEB18056A; Thu, 10 Nov 2022 08:57:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1668088636; bh=LL2SoPPOvswZm85MsT6GvyF3Abmc0fmqHrlmXweOD7Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hlCAj3tREQIT9qiwe4Ly4XUMl0+o/HHaGw3rHhtOKsJ62Z/BYjIGx/OVY2lKMgN9v Hm3VLV9vaw+Hiy3KbTeWUhkaO6c9Fka/WhfdiU5cehuGvgBdJmj3zImaI5q+B67KTZ kOFDSa00CVLcKI+1P2AQl6EYNW/1KJhR1vMS4R1IXcBWdOkKB600Yb5TreaevCGio0 vxPMa8O6w1tR0cAqSxXeTMErmhIU8dgh/BmxCQk+jfgZnZ6X6ahmwnGifRfibBM/Lw UdVdr+VtWzLrmIS0vEpttaFDWKTZveKGr+tzT/Vszjc5c5DB4bnvy8CPZ35TNZ6U6m TlUvJypnS0nIg== Original-Received: from pastel (unknown [104.247.241.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 88F9E120D11; Thu, 10 Nov 2022 08:57:16 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Thu, 10 Nov 2022 10:15:41 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:299488 Archived-At: > Arash, I think your suggestion of recommending `with-eval-after-load` > is pertinent and should be added to the manual. I don't have an objection to that but I consider uses of `with-eval-after-load` as hints that maybe we should do things differently. IOW we should try and change the way this customization is done such that it does not need `with-eval-after-load` any more. The suggestion to split the var in two (one plain var and a custom var that defaults to nil) is such a possible solution. > Eli, even though we provide a healthy dose of built-in server invocations > in that variable, we can't and shouldn't aim at being exhaustive. Seeing the wild number of LSP servers available for some languages, I'd agree, sadly. Maybe to reduce the problem we should allow multiple entries per major mode and use the first that works, without needing to go through `eglot-alternatives`? > That said, I have no objection to converting eglot-server-programs into > a defcustom, if someone will commit to translating and maintaining all > the complex combination of options into "widget" form. I don't have the > time or inclination for this task, but maybe someone has. That variable's type is arguably too complex for a `defcustom`. Maybe the corresponding info should be split into several variables to make it more accessible to users, but I don't have any good idea how to do that. [ I'll note in passing that it's common to use strings for TCP port numbers, especially once they are standardized enough to appear in /etc/services, so maybe the syntax for that TCP connection should replace (HOST PORT ...) with something like (:tcp HOST PORT ...). ] Stefan