-
Notifications
You must be signed in to change notification settings - Fork 54
Design goals
This project aims to be a backend supporting common source code operations as requested by a separate frontend (typically a text editor)
- Support code completion
- Support going to definitions/implementations
- Support going to the documentation
- Support linting
- Support executing a build
- Support other operations that we didn't think of at first
The backend should not be written for a specific editor, and it should be as easy as possible to enable support in another editor.
This to try and prevent the main editor from crashing should this backend crash.
There are many reasons to use Go. While I (@quarnster) was initially put off due to the forced use of egyptian brackets, I finally gave up my shallow reason for rejecting it and I've been continually impressed by its expressiveness and elegance. It's the language I feel the most productive in and I think the language specification encourages writing bug free code, with many of them being caught at compile time.
A complete operation is a complete operation, a goto documentation operation is a goto documentation operation, etc. In other words clients shouldn't have to do anything specific when requesting a complete operation in a java file compared to a C++ file, or even know that the operation is handled by different "intent handlers/drivers/whatever you want to call it".
In practice a complete operation inside of a java file as compared to a C++ file need different information to be able to successfully complete. This information should be provided by executing a "create session" operation providing all settings needed, which creates a session token that can be used in future operation requests.
Operations should be able to override the session settings should that be needed for specific files.
This is not a commercially backed project, but developed and discussed fully in the open with a 2-clause BSD license.
While not 100% possible, it's a good target to aim for. Bug fixes should include a new test to prevent future regressions.
There should be no files written, overwritten, deleted or otherwise modified unless the client specifically asked for it.
While the initial implementation will likely be json encoded data sent via tcp sockets on a local machine, it should be possible to replace this with standard io pipes or to even run the backend "in the cloud". (The idea of a javascript frontend being just as capable as vim, emacs or any other editor certainly excites me.)