Re: Making `eglot-server-programs' a custom variable?

[Eli Zaretskii <eliz@gnu.org>]

> 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.