Emacs package

[duncan-bayne]

Long-time Emacs user here 👋 I discovered this project while looking to see how I could possibly set up remote pairing with a colleague who uses Visual Studio Code.

Is Emacs support on the roadmap? Is anyone else interested in collaborating to make it happen? I'd certainly be up to contribute, although I don't think I have the capacity (or experience) to do it solo.

[msujew]

Hey @duncan-bayne,

currently not on the roadmap, but that's mainly because we don't have a real roadmap. We're currently actively working on getting the IntelliJ platform integration done (#62), which integrates a reusable service process (see here). The service process is taking care of authentication, text/editor syncing, file system handling, etc.

Ideally, once the service process is working as expected, it can be reused in other IDEs (such as Emacs, Eclipse or Neovim) with relatively little effort.

[spoenemann]

Hi @duncan-bayne (and also @alerque for NeoVIM), contributions for such editor integrations are very welcome!

They would probably need to be community-maintained, as our current team of maintainers is not using Emacs or NeoVIM. But there's a clear process for Eclipse Foundation projects to accept new maintainers (based on merit, i.e. a good amount of contributions, plus a nomination and vote by the current committers/maintainers).

We have to think about where would be the best place for the integration code. It might make sense to create new repos under this org (e.g. oct-emacs, oct-neovim).

[spoenemann]

And also 👍 for @msujew's suggestion to use open-collaboration-service-process as a common basis for the integration. This avoids reimplementing stuff like synchronization of deltas, encryption, and other details of the base protocol. It also makes it a lot easier to keep the integrations in sync with the protocol.

(BTW @jonah-iden we could need a README in the service process package 😄)

[jonah-iden]

@spoenemann Yes we definitely should. I should have some time today so i will add a readme to the improvements PR

[alerque]

They would probably need to be community-maintained, as our current team of maintainers is not using Emacs or NeoVIM. But there's a clear process for Eclipse Foundation projects to accept new maintainers (based on merit, i.e. a good amount of contributions, plus a nomination and vote by the current committers/maintainers).

Fair enough.

Would it make more sense to try to start a project on my own (e.g. in my own GH namespace) and get the ball rolling, then get it adopted later, or try to get accepted as a maintainer now based on past ecosystem contributions (I have a lot of FOSS project management and VIM plugin history to show) and spin up a repository now in this org namespace to raise the visibility and attract contributors sooner?

I'd be up for the later, but if it is a closed door I may start pursuing the former.

[msujew]

I'd be up for the later, but if it is a closed door I may start pursuing the former.

I don't think @spoenemann wanted to indicate that it's a closed door - the opposite in fact. Contributions to eclipse foundation projects are always welcome - it's just that maintainance eventually becomes a burden.

Ideally, once a contributor has contributed a meaningful amount of improvements (features/bug fixes/etc) and becomes the owner of some piece of the project, it's a reasonable expectation to onboard them as an official member of the project. A lot of open source projects don't feature such a process, whereas the Eclipse Foundation has the explicit expectation that major contributors to a project eventually become members. That way, they get more privileges within the project, which also makes it easier to maintain their parts of the codebase - in your case for example, that could be by contributing something like the Neovim integration, which we would likely host in a separate repo within this GitHub organization.

@spoenemann We should ask the foundation to create a repo for an Emacs and Neovim integration - in the worst case, we can simply archive those repos, if nothing comes out of it.

[spoenemann]

We have Otterdog as a self-service tool in place for creating repos: eclipse-oct/.eclipsefdn#1

My proposal: @alerque / @duncan-bayne (or anyone else chiming in) feel free to do first steps towards an initial contribution. Once you have something you'd like to propose through a PR, just comment on #138 or #139 and either @msujew or I will create a respective repo where you can submit the PR.