Sad but true. Any ideas what may turn the tide?
I'm glad language server protocol is getting more adoption.
- People have wildly different preferences (TextMate, Sublime, Atom, VScode, vim, emacs, etc.)
- It is really hard to get an online IDE right. The most advanced version is probably Eclipse Che and they have an API to do autosuggest by looking in all the files.
Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22863
"It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd."
I think the better approach is to sync the entire directory so you can do global search and replace and autosuggest.
My idea of how to make the IDE sync work:
1. You click on an icon in GitLab, it is next to where we now show the url for the terminal.
2. The icon opens a url, with a schema specific for our solution (although we should open source the protocol so others can reuse it). In the url is the following information: server and project location, pod and container to connect to, a token to identify the user.
3. Beforehand the user has installed a local client that is registered to handle this type of schema.
4. The filesystem of the container is synched to the users machine by the local client (I propose to a default directory system specific to the local client).
5. The local client also opens up the favorite editor of the user (make this configurable with smart default by seeing what editors are installed via which).
6. The local editor talks to an endpoint of GitLab, similar to how our terminal works.
7. GitLab uses kubernetes/docker exec to run unison and fswatch on the container (this is a different approach that the volume approach suggested in https://github.com/leighmcculloch/docker-unison#docker ).
8. GitLab makes a reference implementation of this for MacOS, using unison and fswatch. The community will hopefully make Linux and Windows clients.
What do people think?
Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22876
In Eclipse Che, we package these language servers for distribution into dynamically deployed agents. so when you start a workspace, your workspace can add a "PHP agent", for example and then we will deploy the language server and then hook up the browser IDE to the language server. To the end user, it feels seamless, but we actually install the language server for them. There are something like 2 dozen languages being built for language servers now. Rust just announced theirs and others are working on C/C++/RAML - even Emacs is getting one. RedHat is working on an advanced Java version and we use CSharp and eventually typescript from Microsoft. We want total interop with VS Code. Eventually Eclipse Orion (an editor) and Eclipse IDE (desktop IDE) will add support.
With Eclipse Che, we provide a simple CLI that lets you live sync your workspace to your desktop IDE. You just "che mount" and we use a fuse-based file system with unison sync to keep the hosted workspaces synchronized with the desktop. You can then use your local IDE and still have your workspaces entirely in the cloud.
These language servers must have access to the project file system, and we are handling that by either embedding the language server into the same container as the workspace, but since we now support compose workspaces where a workspace can be many containers, we are moving all of the language servers to run as separately deployed agent containers. When a user requests a language intellisense, we'll deploy for that workspace an agent container which is volume mounted to the projects in the workspace containers, so that the workspace can have the utilties needed.