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

Ok.

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

For a simple modification, it appears that 

  (add-to-list 'eglot-server-programs '(foo-mode "foo-lsp" "--stdio"))

is enough.

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

I agree that that would be a good thing to have, but that appears to be
something that would require reworking the widget framework, right?

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

Do you mean "we" as in the Emacs core developers?  Then yes, but there
are plenty of packages on ELPA that don't scrutinise themselves to the
same degree.  The reality of this complexity shouldn't just be ignored.

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