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: Sun, 13 Nov 2022 09:43:08 +0200 Message-ID: <83wn7zl2pf.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18654"; 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 Sun Nov 13 08:43:52 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 1ou7eh-0004hV-Sq for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Nov 2022 08:43:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ou7dv-0002jI-T8; Sun, 13 Nov 2022 02:43:03 -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 1ou7du-0002j8-Ko for emacs-devel@gnu.org; Sun, 13 Nov 2022 02:43:02 -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 1ou7du-0006QY-44; Sun, 13 Nov 2022 02:43:02 -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=oxC0wNZR6Eq//0l1p8LKT4SrfEsPzDnGlbZPvbcnfGo=; b=SrifkN47YyEp 6MTj4b4LMb7B/X1dMtRa5kJ0AHFfVMBhLks2Uh8SiGZdUW9CoEKK4yHQ8fgw50kxq/NobNpnFBmGY KJNIoWeOZui/SOoUwZPLz8tFrs5mmuf5iZOmVK5QS/jFxIZvbpTEiVQ4XIxOCrSES+ngaSqMFTcIG dGJe/QEtIaTtyw9LGoE/CBCkNfM6cISp1190Rsgac7EpJggvvXuUc4vss48gbm1eRsaUPJgAsyOcJ MI6O0LG2E8O/ZaGB7oIBgTyu62gTLuXIGLYqAm8r0tYOo8Wi5/6qfbBUPvlLfIvztQgkKgbGhNZI4 pgNBxR1vvnensQbBWGyD2A==; 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 1ou7dt-0000eH-98; Sun, 13 Nov 2022 02:43:01 -0500 In-Reply-To: <87k03zwcpm.fsf@posteo.net> (message from Philip Kaludercic on Sun, 13 Nov 2022 07:11:33 +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:299711 Archived-At: > From: Philip Kaludercic > Cc: jporterbugs@gmail.com, arash@gnu.org, emacs-devel@gnu.org, > joaotavora@gmail.com > Date: Sun, 13 Nov 2022 07:11:33 +0000 > > Eli Zaretskii writes: > > >> > The :set function of eglot-user-server-programs then > >> > takes care of doing whatever is needed to make sure that the value of > >> > eglot-server-programs is modified according to > >> > eglot-user-server-programs's value when Eglot is started. > >> > >> This I understand, but I don't see how this is preferable to a general > >> solution that doesn't require explicit support for any user option. > > > > What is the general solution you have in mind? And what problems does > > that general solution solve? > > That all user options containing lists can be modified, without each > user option containing lists explicitly accommodating the fact using > some other variable. 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. Alternatively, it requires adding infrastructure to Custom to make these aspects safer and more easily understandable (something I'm not even sure is feasible). My proposal is free from all those disadvantages, because it leaves the complexity to the :set function, which can do whatever it takes without bothering users. In general, I consider user options whose values are complex data structure to be a Bad Thing, due to the difficulties they cause in customizing them. If we limit such options to just the absolute minimum, the "each user option containing lists" problem you envision should not exist. We should strive to present to users a simpler customization interface, in the form of simple variables whose effects are easily documented and understood, and make their :set functions change the complex data structures as needed under the hood. 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.