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

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

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

Yes.