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

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

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.
>
> To implement non-standard LSP features, which lots of servers propose.

Yes, that's one of the possibilities.  Another possibility is offering a
different, perhaps richer interface to programming facilities specific
to the major mode which may or may not rely on Eglot's LSP.  For
example, if LSP isn't available, or isn't the best choice for a
particular feature (say completion, or definition-finding) this
interface might delegate to some other tool, to CEDET, etc.

>> [...] Also, once Eglot is in core, I won't be only person deciding.
>
> (I welcome Eglot's inclusion in the core and appreciate your work.  I
> hope that's clear.)

And I hope it's clear that I immensely appreciate your work and your
review efforts in Eglot.  Eglot doesn't have many contributors who
understand the code base well (and bringing it to core is also an effort
to change that).

>>> 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.
>
> OK.  This is somewhat similar to the case when a major mode provides an
> xref or a flymake backend.
>
> But I think sometimes the reverse approach is more desirable.  Let's
> take a not so hypothetical example and say c++-mode wants to provide a
> type-hierarchy browser.  It's better to write a generic, language
> agnostic hierarchy browser (maybe CEDET even has one), and extend Eglot
> with a hierarchy browser backend similarly to its xref backend.  The
> hierarchy browser then can have a tree-sitter backend as well.

Yes, I fully agree.

>> 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. 
>
> I agree, but non-standard extensions exist for a reason.

Yup, it's normal.  You see the same in programming extensions that
appear in specific compilers first.  Some of then make it to the
standards, some don't.  Sometimes they make it in largely unchanged and
adapting clients is easy, sometimes not so much.  Standardization is
hard.

> Almost all servers have a VS-Code specific part that contains at least a
> list of configuration variables that other clients cannot handle
> automatically.  BTW, if Eglot knew about these configuration variables,
> could `customize-group` somehow save the settings into a .dir-locals.el
> file?

Very interesting.  Yes, I think this is a great idea to allow the user
to configure server-specific things easily and automatically save it
.dir-locals.el.  People tend to struggle with that, and it's 

The question is how.  Not sure if variables is the way to go.  It
_could_ be (but it could also be some plist/alist).  But let's say it's
variables, i.e. symbols holding values.  Then these symbols belong to
the major mode, not to server-agnostic eglot.el.  Then maybe each such
variable could have a symbol property 'eglot--server-specific-section'
and 'eglot--server-specific-name'.  Then there could indeed be a command
M-x eglot-save-server-specific-variables that creates/updates
.dir-locals.el for the given project.

Maybe custom.el machinery could call that command automatically. But for
which projects?  All of them?  The "current" one?  We don't have
project-specific custom.el

And also when using variables I always think its nice not to force
custom.el the user.  I know others like me prefer to set things from
.emacs.  So it should work without it.

>> 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.
>
> Even clangd has a moderately long list of extensions:
> https://clangd.llvm.org/extensions.html#type-hierarchy
> Sure, clangd is usable without them, but some of the extensions might
> make someone's life easier, for example, by providing a type hierarchy
> browser.

Writing more C++ lately I do feel this need yes.  I was looking at
tree-widget.el the other day, but didn't make much progress.  I fully
agree to what you we should make some backend-agnostic frontend first
and then plug it into eglot.el or eglot-x.el

>> [...] So there isn't any problem/drama here.
> I don't want to start one either, but it's a good time to think once
> more about Eglot's relations with other packages.

Aye, and that's always the thing with Eglot: it's at the intersection of
many things.

João