On Sat, May 9, 2020 at 6:58 PM Yuan Fu <casouri@gmail.com> wrote:

>
> 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