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

[Philip Kaludercic <philipk@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

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

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'?