João Távora [2022-11-10 15:21:46] wrote:
> 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.
I have 4 uses of it in my ~75kB init file.
It's a great tool, but still one where I consider that imposing it on
the user is a sign of a deficiency (a bit like advice, tho much less
severely so).
That doesn't mean we have to find a way to avoid its use, just that it
would be nice to find such a way.
>>> 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 :-)
In my experience it's usually a reflection of the fact the LSP protocol
leaves a bit too much control to the server, which should focus on
providing "impartial info" about the language, leaving more of the
choices of how to use that info somewhere in the hands of the end user.
"Choose an LSP server" seems to me like a very poor way to customize the
behavior of the server.
IOW the design of the LSP protocol is not "Emacs-y" enough :-)
>> 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'm just suggesting directions. I don't claim they're the right answer.
My impression is that this variable is currently both "too complex" and
"not flexible enough". Don't get me wrong, it's good enough for now.
But no, I don't have a good replacement to suggest. My gut just tells
me that there is a better arrangement.
>> [ 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.
I think currently an entry cannot start with a keyword, so te syntax
I propose wouldn't break compatibility. But it would be different in
style from what's there currently, making it more complex for the user.
So I think it would only make sense if/when we make other changes at the
same time.
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