Re: Eglot to core [Was: rmsbolt.el [Was: Colorful line numbers]]

[João Távora]

Felician Nemeth <felician.nemeth@gmail.com> writes:

> I don't think the current API is good enough for that.  See
> https://github.com/joaotavora/eglot/discussions/802#discussioncomment-2171239

Really depends on what you consider "that" to be.  I know you have an
eglot-x.el package and I haven't had time to look at it.  If you propose
to expand the API of eglot.el with well-grounded use cases, I'm happy to
take it.  Also, once Eglot is in core, I won't be only person deciding.

> More importantly, there are multiple language server implementations for
> some languages (python, c) with different quirks or non-standard
> extensions to the LSP protocol.  How do you imagine a major-mode would
> support these?

They can adds methods to the generic function eglot-handle-request (and
a handful others), set values of Eglot in their major-mode
initialization code, bind keys to `eglot-*` interactive commands, make
compound commands from those commands, etc.

While they _can_, but that doesn't mean they _must_ or even _should_.
In fact, LSP's whole idea, which is surprisingly forgotten so often, is
that server and editor need to know very little about each other to be
able to cooperate.  By and large this idea works very very well.  Eglot
works with tens of servers and hasn't got a line of server specific
code, except for eglot-server-programs invocations.  There are
exceptions, and not everyone has the same luck, but I've been using C++
clangd and C# omnisharp quite a lot lately and I have 0 lines of server
specific config.

> Authors of a major-mode even rejected to configure eglot-server-programs
> in their mode saying it didn't belong to there.  (Unfortunately, I
> cannot find the github discussion for this.)

I can't either, but I do remember it.  One (1) author of a
javascript-ish major mode rejected this, and I'm not sure this person
was seeing the complete picture.  Anyway, I can't foresee the future,
but I don't see many major mode authors objecting to setting font-lock-*
or imenu-* or many other things in their major modes.  Major modes
usually use transversal facilities in Emacs, and I wish for Eglot to
gradually become one such facility.

If you don't work like this you'll have "ghost" major-modes like
`eglot-java.el`, `eglot-python.el`, with their own maintainers, their
own philosophies, and eventually you're back to the beginning
duplicating and rewriting all the code that LSP wants you to avoid
doing.

But it's true: I have seen one author here offer resistance to setting a
single flymake- variable in the major mode, even though Flymake was in
the core.  I think it boils down to the fact that Flymake wasn't even
known or popular with this person or, admittedly, even spectacularly
useful out-of-the-box, at least not when compared to what it does when
Flymake/Eglot/LSP combo.

Nonetheless, I'd say eglot-server-programs and the current status quo
isn't going anywhere for now.  

So there isn't any problem/drama here.  I definitely don't want to be
breaking things in eglot.el.  I was just stating the general direction.

João