What advantage would splitting and “diluting” eglot into Emacs give tho? I think eglot works pretty well already, one just installs eglot and a server and everything works.
Not many immediate "killer" advantages, Yuan Fu, but:
- eglot.el would be simplified, tho maybe only slightly. That is good.
- language specific quirks (that do exist despite LSP) would be dealt
with in the corresponding mode, not Eglot, by using Eglot's
existing interfaces.
- Eglot could grow _more_ programmatic interfaces for that
to happen. It doesn't have them because it's the chicken and
the egg.
- More importantly, many bugs that target Eglot's UI but are actually
Emacs's would come here. Discussing them in Github and hailing (mostly)
Stefan and Dmitry there works, sort of, but it would be better if we used the
Emacs bug tracker (yes I know there are strong opinions on this). But at
the very least people like Eli and Richard would be able to participate
regularly in those discussions, and provide insight that just doesn't
reach the Github-sphere.
The dev version of eglot would have always nicer integration with
eldoc.el, flymake.el, xref.el, project.el, so it would become a much
better program. And it could still be distributed in GNU Elpa, for
older versions of Emacs to use.
Let me give you an example: didn't your eglot-box thing end up being
an eldoc-box instead? It should be in eldoc.el, it's a pretty good idea!
Well if eglot was in the core, you'd just automatically do it for eldoc.el
and get help on how to do it from seasoned Elispers who hang around
here and not Github.
João