From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Making `eglot-server-programs' a custom variable? Date: Wed, 16 Nov 2022 13:05:46 +0000 Message-ID: <87fsejnj6d.fsf@posteo.net> 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> <831qq4hyo9.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="36857"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, arash@gnu.org, emacs-devel@gnu.org, joaotavora@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 16 14:07:16 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 1ovI8I-0009ID-Sd for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Nov 2022 14:07:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovI7P-0004KX-O2; Wed, 16 Nov 2022 08:06:29 -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 1ovI6z-0004Js-12 for emacs-devel@gnu.org; Wed, 16 Nov 2022 08:05:53 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovI6w-0004Hw-7d for emacs-devel@gnu.org; Wed, 16 Nov 2022 08:05:52 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B1F16240107 for ; Wed, 16 Nov 2022 14:05:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668603947; bh=4XXVaOYonTK/C7prVmT/T+JjuyD4hLBXSb0EJTWZe6A=; h=From:To:Cc:Subject:Date:From; b=SOGys/EVx84/A6DeEJNRcCJYqXRuvF+/MiOPgYG/q2QXhAHi+f2QJbgtG8tSwAILo No6O3a9XZmemX48EYw7ySvub8k064wY4GYDgigim7CAIS+PnI03MmGk09kJQsqA2Ha mX/zlr552ZiY5prVPfXRjrtf+Opg0isl00Oy+0f05/3pLkZThwWLaEcsCLvFYzmeVK FQkcOmuSYSS3ICHLtnOsMX64pWMfzRBuJB8ha4Z0FeKfNev0R6w8ZsXsaI8dvjT3ER nlydig/FOQiPUpZwNhGa7q2CoNO2MgZ7grqaQot89qYZHKwa7vaHhTSHDJl8YXXGTG RbgOHQPa0Cwig== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NC3FQ5klTz9rxN; Wed, 16 Nov 2022 14:05:46 +0100 (CET) In-Reply-To: <831qq4hyo9.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Nov 2022 20:15:18 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:299917 Archived-At: Eli Zaretskii writes: >> 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. Ok. >> `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? For a simple modification, it appears that (add-to-list 'eglot-server-programs '(foo-mode "foo-lsp" "--stdio")) is enough. >> > 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. I agree that that would be a good thing to have, but that appears to be something that would require reworking the widget framework, right? >> 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. Do you mean "we" as in the Emacs core developers? Then yes, but there are plenty of packages on ELPA that don't scrutinise themselves to the same degree. The reality of this complexity shouldn't just be ignored. >> > 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!