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 12:43:09 -0500 Message-ID: References: <86fservpri.fsf@gnu.org> <878rkial85.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31035"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) 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 18:44:26 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 1otBbF-0007rA-N1 for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Nov 2022 18:44:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1otBaQ-0007EZ-F5; Thu, 10 Nov 2022 12:43:34 -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 1otBaK-0007DO-SR for emacs-devel@gnu.org; Thu, 10 Nov 2022 12:43:32 -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 1otBa8-0003iT-IR; Thu, 10 Nov 2022 12:43:28 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C224F4407BD; Thu, 10 Nov 2022 12:43:12 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E998E4404A8; Thu, 10 Nov 2022 12:43:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1668102191; bh=DyplkSH9TWPQafLT+sjohAV/1RVvf72vdBr9TKDwimY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Vmte8l8N+MDNuMjcKbLtyoma2oPkMH9taFR6PhoHVS+Qx97RYtsZ6xacVYxOpvhc4 IaL7a9lFHdbMBJzccgl6rSbUsfjZvigFDcLM8Dhq15fjLDrG3ogS9Pc0ol94DTLemh sqMFGm87a4VDrXJACrKGMHpd264M4Vs/JzZRqwut/WNqCzsFeih6D20WEUbycv73L1 kn6/fWxMCXnxjD4nUVQ/TeJgblrqQaMSN32pjx0emxXRbkS4RqqOjYa9MTSktg5p1i VJPu5TWn1Mrl7GaGlimY1Al6tIWu2uhcGSTddvyUKJ2JzmsLVlrKX7SxA05H4d98Ju ZeSoJa76ci2ZQ== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C8404120BFC; Thu, 10 Nov 2022 12:43:10 -0500 (EST) In-Reply-To: <878rkial85.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Thu, 10 Nov 2022 15:21:46 +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: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299501 Archived-At: Jo=E3o T=E1vora [2022-11-10 15:21:46] wrote: > Stefan Monnier writes: >>> 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. > Why? This is in a user's init file. I can more or less see that > argument for inter-library dependencies. But here, w-e-a-load is > exactly what's needed. I use it all the time in my config. I have 4 uses of it in my ~75kB init file. It's a great tool, but still one where I consider that imposing it on the user is a sign of a deficiency (a bit like advice, tho much less severely so). That doesn't mean we have to find a way to avoid its use, just that it would be nice to find such a way. >>> Eli, even though we provide a healthy dose of built-in server invocatio= ns >>> 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. > I don't think this is sad :-) In my experience it's usually a reflection of the fact the LSP protocol leaves a bit too much control to the server, which should focus on providing "impartial info" about the language, leaving more of the choices of how to use that info somewhere in the hands of the end user. "Choose an LSP server" seems to me like a very poor way to customize the behavior of the server. IOW the design of the LSP protocol is not "Emacs-y" enough :-) >> 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`? > > Again, why? Why add more semantics to an already complicated variable > when the functional eglot-alternatives plugin works fine? Furthermore, > I'd like to this particular configuration for a future > multiple-simultaneous-server-in-one-mode idea. I'm just suggesting directions. I don't claim they're the right answer. My impression is that this variable is currently both "too complex" and "not flexible enough". Don't get me wrong, it's good enough for now. But no, I don't have a good replacement to suggest. My gut just tells me that there is a better arrangement. >> [ 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 ...). ] > If you can make that change without breaking backward compatibility, I > have no objections. I think currently an entry cannot start with a keyword, so te syntax I propose wouldn't break compatibility. But it would be different in style from what's there currently, making it more complex for the user. So I think it would only make sense if/when we make other changes at the same time. Stefan