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