On Thu, Sep 8, 2022 at 1:34 PM Payas Relekar <relekarpayas@gmail.com> wrote:

> I remember reading a discussion on possibly merging Eglot (language
> server client) to Emacs core. I also distinctly remember author wished
> to hack on it in the core after merging.
>
> Since it is already on ELPA, are there any more blockers to merge it?


Hi,

The only blocker -- as far as I am aware -- is the amount of time I have
to dedicate to this.

A sequence of concrete actions needs to be laid down to reach these
objectives:

1. Eglot in core, as a :core ELPA package, so that anyone with
   emacs.git commit rights can push to it to release new versions to
   ELPA. People running trunk emacs.git can get the Eglot bleeding
   edge of course.

2. Preserve the full Git history of the eglot.el file after it has been
   merged.

3. Adapt the tests in eglot-tests.el into Emacs's test suite (shouldn't
   be terribly difficult, they are both ert-based). The most interesting
  and useful tests need LSP servers, so one should investigate if these
  can be installed in Hydra.

4. Check carefully for copyright assignments for Eglot's many
   contributors.  I've been careful with this since day 1, but this
   needs to be double checked.  Some contributions are
   "Copyright-paperwork-exempt".

5. Arrange for the eglot.el file in Eglot's current upstream --
   https://github.com/joaotavora/eglot -- to mirror
   src/progmodes/eglot.el, ideally (but not necessarily) automatically

   This is so that:

   5.1 Users of bare Git clones can continue mostly unimpeded.

   5.2 GitHub users can still suggest changes as "Pull Requests"
       via GitHub's interface

   5.3 The current GitHub actions CI -- where installation of third-party
       language servers is relatively easy -- can run at least the current
       eglot-tests.el.

6. Adapt the README.md into a manual section in TexInfo format.

Items 2 and 5 are the ones I'm not 100% sure on how to make
happen. But I'm pretty sure they are possible given sufficient Git
skills.

If anyone can help with any of these items, it would be most welcome
and speed up the process.

"Help" can mean simply fleshing out the item into concrete actions,
anticipating problems, etc..  It can also mean actually doing those
actions.  I don't think there are many dependencies between the items,
so multiple people can work concurrently..

I'm also interested in comments about this plan, its objectives,
alternatives, etc... Those are welcome, though I'd rather not waste
too much time on alternatives such as "forget about Git history",
"just bury the GitHub repo", "the manual can come later",
"ditch the CI", etc...

Thank you,
João