> 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.
IOW we should try and change the way this customization is done such that it
does not need `with-eval-after-load` any more.
The suggestion to split the var in two (one plain var and a custom var
that defaults to nil) is such a possible solution.
> 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.
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`?
> That said, I have no objection to converting eglot-server-programs into
> a defcustom, if someone will commit to translating and maintaining all
> the complex combination of options into "widget" form. I don't have the
> time or inclination for this task, but maybe someone has.
That variable's type is arguably too complex for a `defcustom`.
Maybe the corresponding info should be split into several variables to
make it more accessible to users, but I don't have any good idea how to
do that.
[ 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 ...). ]
Stefan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4