> From: Philip Kaludercic <philipk@posteo.net> > 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 <eliz@gnu.org> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4