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: Tue, 15 Nov 2022 17:50:25 +0000 Message-ID: <87fsek6ra6.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32983"; 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 Tue Nov 15 18:51:31 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 1ov05r-0008L7-5v for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 18:51:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ov05N-00062C-7a; Tue, 15 Nov 2022 12:51:01 -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 1ov04x-0005nt-N7 for emacs-devel@gnu.org; Tue, 15 Nov 2022 12:50:36 -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 1ov04s-0005Qk-EH for emacs-devel@gnu.org; Tue, 15 Nov 2022 12:50:34 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8693A240103 for ; Tue, 15 Nov 2022 18:50:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668534627; bh=Yzy/P/tdmB6dr1TVe9jhgNl4CgLnZKL3Xb+BtBqwG5c=; h=From:To:Cc:Subject:Date:From; b=KytJin5IkBmSI6AsOCEpsjsW6F4LM+mAB6+AQoBJ49KOxTqLEqdatuisd5cxwfcfd FdK/26UX+WLg0hoNyAjs1v3Ue0Av3Kr1umSZOvtJaz/pAq7W0PeTspwIRHwZbJeTao hwl2GkI/Up9zER+H1XYZTk8KGYbGU4UbDBeMC549FgZ5ddHdN10MPonVQctUjC6TQh 7KnbJVRMaug4RYX5qFFMCuzYPpVQQu919GFVNKDSGbK4CC2BBVstxMptWd0PZcZTSc r4vuTQNwYSWK/gOwxIfdLh0uAbCbvVgH7CUWjch2oitlBhm1/SavZQdmDfWTd5cotR NKLwhlGX/Ak9Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NBYcK51hbz9rxQ; Tue, 15 Nov 2022 18:50:25 +0100 (CET) In-Reply-To: <83wn7zl2pf.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 13 Nov 2022 09:43:08 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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:299862 Archived-At: Eli Zaretskii writes: >> 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. Where do you draw the line to what is "complex" and what isn't? `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. > 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? ;; Check that the type is correct. (when-let ((type (get variable 'custom-type))) (unless (widget-apply (widget-convert type) :match value) (user-error "Value `%S' does not match type %s" value type))) > 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. FWIW I agree that user options shouldn't be too complicated, but knowing how to simplify a user option is an art in itself. > 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? Or `display-buffer-alist'?