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: Wed, 16 Nov 2022 13:05:46 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >   (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.
>
> And we expect a random user to know this how?

I believe it to be no more or less reasonable to know than how to
manipulate `auto-mode-alist', and that involves Elisp regular
expressions.

If something like this is mentioned in the manual, I think that should
suffice for a "learning-by-template" approach, which is my impression of
how most people use Emacs.

>> >> > 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?
>
> Probably.  Which is why I think my original proposal, not to ask users
> to customize such variables directly, is much easier to implement.

I don't think that either or differs too much in difficulty, this is
more a question of approach.