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

["João Távora" <joaotavora@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Arash, I think your suggestion of recommending `with-eval-after-load`
>> is pertinent and should be added to the manual.
> I don't have an objection to that but I consider uses of
> `with-eval-after-load` as hints that maybe we should do things
> differently.

Why?  This is in a user's init file.  I can more or less see that
argument for inter-library dependencies.  But here, w-e-a-load is
exactly what's needed.  I use it all the time in my config.

The reason people probably didn't need this earlier is because they were
using Eglot from a package and were simply adding

  (require 'eglot)
  (add-to-list ...)

Or they were doing that use-package magic, which probably does the same
something similar to the require or the w-e-a-load strategy.

> The suggestion to split the var in two (one plain var and a custom var
> that defaults to nil) is such a possible solution.

That would just break user's configurations and complicate things for no
reason.  add-to-list is the way to go, and with-eval-after-load (or
use-package if you must) is just there for that.  Composing existing
pieces that do one job well is better than inventing and maintaining new
pieces.

>> Eli, even though we provide a healthy dose of built-in server invocations
>> in that variable, we can't and shouldn't aim at being exhaustive.
> Seeing the wild number of LSP servers available for some languages, I'd
> agree, sadly.

I don't think this is sad :-)

> Maybe to reduce the problem we should allow multiple entries per
> major mode and use the first that works, without needing to go through
> `eglot-alternatives`?

Again, why?  Why add more semantics to an already complicated variable
when the functional eglot-alternatives plugin works fine?  Furthermore,
I'd like to this particular configuration for a future
multiple-simultaneous-server-in-one-mode idea.

> [ I'll note in passing that it's common to use strings for TCP port
>   numbers, especially once they are standardized enough to appear in
>   /etc/services, so maybe the syntax for that TCP connection should
>   replace (HOST PORT ...) with something like (:tcp HOST PORT ...).  ]

If you can make that change without breaking backward compatibility, I
have no objections.