From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Making `eglot-server-programs' a custom variable? Date: Tue, 15 Nov 2022 20:15:18 +0200 Message-ID: <831qq4hyo9.fsf@gnu.org> References: <86fservpri.fsf@gnu.org> <87cz9v97lo.fsf@posteo.net> <86r0yb234t.fsf@gnu.org> <87o7te7lc7.fsf@posteo.net> <83sfioob7s.fsf@gnu.org> <87wn80zjiw.fsf@posteo.net> <83leogo9yw.fsf@gnu.org> <87r0y8zhl9.fsf@posteo.net> <83k040o8an.fsf@gnu.org> <87mt8wzf20.fsf@posteo.net> <83edu8o5gw.fsf@gnu.org> <878rkgz3nj.fsf@posteo.net> <83r0y8meis.fsf@gnu.org> <87wn7zwvqk.fsf@posteo.net> <83a64vmk8l.fsf@gnu.org> <87k03zwcpm.fsf@posteo.net> <83wn7zl2pf.fsf@gnu.org> <87fsek6ra6.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22260"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, arash@gnu.org, emacs-devel@gnu.org, joaotavora@gmail.com To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 19:16:02 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 1ov0Ta-0005Vm-7H for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 19:16:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ov0Sm-0002Ts-MH; Tue, 15 Nov 2022 13:15:12 -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 1ov0Sl-0002SG-7M for emacs-devel@gnu.org; Tue, 15 Nov 2022 13:15:11 -0500 Original-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 ) id 1ov0Sg-0001b6-6z; Tue, 15 Nov 2022 13:15:10 -0500 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=b+WaSu+ia05s7UL1Bq1FE982bkR50bQcHzVbdUuxVqE=; b=qQPqu+5ps8ST nVl/bfuHCuUARn4lCp/dj0vXgL/L+QSvyVj7Czxxo++s5xBWBxVGlOC1l2Rdc7+TSu7y6ke7v36+e Cp4HltR33mpxUAcBiKCG04fCbWO8wo1ukoUcCHP7iWWROCEANQpmPj50+JCWfRazh27ZqDjH/n6y5 ImZCzEmDZdkiwW0tNM9awcTE+iWx/xqvsNKexQLZDXCPOV9AYyLDkx8pEiM1z14X8hsrLNMHqzKhU 5+74dMjZMB8EPO1DOFu7smcoeNkw2AN94tYvH4Hzzx+77JANAANG5D9mCPHIiQhbD5jHjWDttckSu n5ejrM3fOOKDAzTHpG5E6g==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ov0Se-0008Ox-P9; Tue, 15 Nov 2022 13:15:05 -0500 In-Reply-To: <87fsek6ra6.fsf@posteo.net> (message from Philip Kaludercic on Tue, 15 Nov 2022 17:50:25 +0000) 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:299864 Archived-At: > From: Philip Kaludercic > Cc: jporterbugs@gmail.com, arash@gnu.org, emacs-devel@gnu.org, > joaotavora@gmail.com > Date: Tue, 15 Nov 2022 17:50:25 +0000 > > > The problem is only with user options that have complex structures. > > Letting users edit such data structures directly is wrought with > > unnecessary risks, and requires users to understand very well the > > semantics of the data structure and the effect of every change in it. > > Where do you draw the line to what is "complex" and what isn't? Basically, anything that is not an atom is "complex" for this purpose, in my book. > `eglot-server-programs' is complex in the trivial sense that it is made > up of multiple parts, but each entry is relatively independent, and > pretending an element to the beginning of the list shouldn't involve any > unexpected surprises. Let's look at this from the user's POV, okay? (defvar eglot-server-programs `((rust-mode . ,(eglot-alternatives '("rust-analyzer" "rls"))) (cmake-mode . ("cmake-language-server")) (vimrc-mode . ("vim-language-server" "--stdio")) (python-mode . ,(eglot-alternatives '("pylsp" "pyls" ("pyright-langserver" "--stdio") "jedi-language-server"))) ((js-json-mode json-mode) . ,(eglot-alternatives '(("vscode-json-language-server" "--stdio") ("json-languageserver" "--stdio")))) Here we have: . a multi-level list . elements that are alists . a "backquote construct" with evaluated parts in How much Lisp do we require a user to know? Imagine a user who just wants to add one more server, either for an existing mode or for a new mode not in the list. Do we really expect him or her to understand all that? > > Alternatively, it requires adding infrastructure to Custom to make > > these aspects safer and more easily understandable (something I'm not > > even sure is feasible). > > Like `setopt' does with primitive type checking? Yes, but much more complex. Essentially, display the above list in a form that is easy to understand, and allow updating it in that form. > FWIW I agree that user options shouldn't be too complicated, but knowing > how to simplify a user option is an art in itself. Yes, but IMO we should bite that bullet every time. > > The proliferation of user options with complex values we have > > currently in Emacs is a bad tendency that is at least in part due to > > the fact that the developers have no problems dealing with such data > > structures. IMNSHO, we don't think enough about our users when we > > introduce such options. > > Again, I am uncertain what you mean by complex. Is `auto-mode-alist' > complex? To some extent, yes. > Or `display-buffer-alist'? Definitely!