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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: jporterbugs@gmail.com,  arash@gnu.org,  emacs-devel@gnu.org,
>   joaotavora@gmail.com
> Date: Tue, 15 Nov 2022 17:50:25 +0000
> 
> > 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?

Basically, anything that is not an atom is "complex" for this purpose,
in my book.

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

Let's look at this from the user's POV, okay?

  (defvar eglot-server-programs `((rust-mode . ,(eglot-alternatives 
'("rust-analyzer" "rls")))
                                  (cmake-mode . ("cmake-language-server"))
                                  (vimrc-mode . ("vim-language-server" 
"--stdio"))
                                  (python-mode
                                   . ,(eglot-alternatives
                                       '("pylsp" "pyls" ("pyright-langserver" 
"--stdio") "jedi-language-server")))
                                  ((js-json-mode json-mode) . 
,(eglot-alternatives '(("vscode-json-language-server" "--stdio") 
("json-languageserver" "--stdio"))))

Here we have:

 . a multi-level list
 . elements that are alists
 . a "backquote construct" with evaluated parts in 

How much Lisp do we require a user to know?  Imagine a user who just
wants to add one more server, either for an existing mode or for a new
mode not in the list.  Do we really expect him or her to understand
all that?

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

Yes, but much more complex.  Essentially, display the above list in a
form that is easy to understand, and allow updating it in that form.

> FWIW I agree that user options shouldn't be too complicated, but knowing
> how to simplify a user option is an art in itself.

Yes, but IMO we should bite that bullet every time.

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

To some extent, yes.

> Or `display-buffer-alist'?

Definitely!