Support other editors

[gaocegege]

Language server is supported by many editors/IDEs.

We could support them by different client in these editors/IDEs and same language server.

This is a long-term task.

• VS Code
• Eclipse Che
• Eclipse IDE(Eclipse LSP4E) (We already have https://github.com/coala/coala-eclipse)
• emacs (We already have https://github.com/coala/coala-emacs)

Third party support for LSP:

• sourcegraph/sublime-lsp
• OmniSharp/atom-languageclient
• autozimu/LanguageClient-neovim

[Makman2]

You think we can write a coala/language-server repo? :)

[gaocegege]

Yeah, that's my opinion. and maybe lang-server could be a submodule in this repo.
😄

[Makman2]

Let's see whether we want to use submodules (actually I've made not so good experiences with them, I often had conflicts which involved clearing the git cache by hand), maybe there's another dependency mechanism we can use 👍

[gaocegege]

Yeah, I'm not good at git, too. Conflicts are annoying. It's better to have a simple way to organize code.

[gaocegege]

Third party support for LSP:

• sourcegraph/sublime-lsp
• OmniSharp/atom-languageclient

It is better to maintain one language server and some clients in different editors. For test and devel.

I'll try to do a feasibility analysis.

[gaocegege]

Feasibility Analysis

Background

coala have a few editor plugins but it is unmaintainable, the community has to explore the possibility of having a single git repository for atom, sublime-text and vim as it will ultimately be easier to maintain in the long run. Refer to cohesive editor support - projects.coala.io for further details :)

Description

Language server protocol(LSP) is a protocol for editors to support language-specific services, it's a potential solution to the problem. It is a mature protocol now but only a few editors have native support for the protocol:

Editor/IDE	Maintainer
VS Code	MS	vscode
Eclipse Che	Eclipse,Codenvy/TypeFox	Che
Eclipse IDE	Eclipse,Red Hat	Eclipse community, Eclipse LSP4E
emacs	Vibhav Pant	emacs language server client
GNOME Builder	gnome.org	language server client

Besides those native supported editors, there are some third party integrations:

• sourcegraph/sublime-lsp for sublime text
• OmniSharp/atom-languageclient for atom

LSP allows us to write a language server for coala in python as the backend to all plugins and clients for every plugins to interact with the backend server. php-language-server is an example to illustrate the architecture. It is a PHP server and used by many different clients.

Good Points

It's easy to test and maintain if we refactor all plugins to support LSP. Server and client are decoupled and have their own test cases.

And LSP is adapted by more and more editors and it is easy to extend coala support to other platforms in the future.

Bad Points

Unfortunately, those two third party supports are not in active development and it is believed that we have to fix bugs on our own if we encounter errors caused by the third party support and the patches may not be merged into master which means we have to maintain forks of those two languageclients.

And the performance is another problem we might meet with. LSP increases overhead compared to the existing implementation, it adds a new abstract(client/server abstraction) layer into plugins. I'm not sure whether it is accepted by the users because editing should be real-time and now coala-plugins are already slow.

WDYT

[Makman2]

Your idea sounds good. 1. We remove redundancy on our side 2. everyone gets something from maintained LSP plugins for editors that don't support it.

Unfortunately, those two third party supports are not in active development and it is believed that we have to fix bugs on our own if we encounter errors caused by the third party support and the patches may not be merged into master which means we have to maintain forks of those two languageclients.

Those plugins should have open contribution licenses so this shouldn't be a problem :)

And the performance is another problem we might meet with. LSP increases overhead compared to the existing implementation, it adds a new abstract(client/server abstraction) layer into plugins. I'm not sure whether it is accepted by the users because editing should be real-time and now coala-plugins are already slow.

I think LSP shouldn't slow it down that much. I believe that coala will use up way more time/CPU than the editor integration itself in many cases.

Also: IntelliJ does not execute analysis while the user is typing, it waits a second an then rechecks the code, and this is imo a good approach. If the editor does the checks on each new letter typed, the editor definitely needs to change behaviour to achieve a better user experience.

[gaocegege]

Those plugins should have open contribution licenses so this shouldn't be a problem :)

Yeah but I think the motivation of this idea is to reduce the dev work, maintaining multiple LSP client implementations is a hard task.

I think LSP shouldn't slow it down that much. I believe that coala will use up way more time/CPU than the editor integration itself in many cases.

It makes sense:)

Anyway, I'll prepare a proposal for cohesive editor support - projects.coala.io.

[Makman2]

Yeah but I think the motivation of this idea is to reduce the dev work, maintaining multiple LSP client implementations is a hard task.

Or we maintain a bunch of plugins directly using coala, like we do currently ;D not really different except that your concept is more structured and offers more features :)

Anyway, I'll prepare a proposal for cohesive editor support - projects.coala.io.

sounds good :D

[RohanVB]

Hi, I currently have the last merged PR on the objective of Cohesive Editor Support which defines a different approach instead of just using LSP for the plugins. I'll just weigh in on my opinion here :

1. Support, ie. testing and documentation (specific to that project) should be focussed on the existing main coala plugins.
2. Since our main plugins include Sublime-text, atom, vim, emacs and gedit out of which only emacs is supported by LSP; it wouldn't be a viable approach to 1)
3. Alternative methods should be explored for developing new plugins, separate from this project (which is the basis of the VS Code repo).
4. Other plugins that are bound to come up with different approaches are jenkins, jetbrains and notepad++, for which this approach won’t be viable either, lacking native support.

In conclusion, (IMO) the LSP approach is a potential solution for the VS Code plugin at the moment; but it is probably not viable for the Cohesive Editor Support project that was proposed.

CC @gaocegege

[gaocegege]

Hi, @RohanVB

Thanks for your reply :)

Support, ie. testing and documentation (specific to that project) should be focussed on the existing main coala plugins.

Yeah, I agree with that.

Since our main plugins include Sublime-text, atom, vim, emacs and gedit out of which only emacs is supported by LSP; it wouldn't be a viable approach to 1)

Sure. It means a lot of work to do if we ship to LSP and it's a potential risk.

Other plugins that are bound to come up with different approaches are jenkins, jetbrains and notepad++, for which this approach won’t be viable either, lacking native support.

Yeah, the focus of the poject is editor-based plugins, I'm working on Create Jenkins Plugins, too. It couldn't reuse the LSP server.

Actually I 'm not familiar with the background of the project, but I think LSP is a potential solution when I read this paragraph. It makes plugins maintainable but also has a lot of works to do.

We could discuss it a little more 😃 I'll give up the project and invest effort in Create Jenkins Plugins if you have a better idea.

[RohanVB]

We could discuss it a little more

Hey @gaocegege I was busy with exams for a few days :D. Continuing the discussion...

Actually I 'm not familiar with the background of the project, but I think LSP is a potential solution when I read this paragraph. It makes plugins maintainable but also has a lot of works to do.

I think the LSP is a potential solution to part of the problem. We should probably have the testing environments for our main plugins on higher priority. That paragraph discusses maintainability, but in doing so our focus would shift to the plugins with lower priority that do happen to support LSP. For starters, in that scenario we would probably have to do the following (crude version):

1. From the existing main repos, emacs would need to first have a LSP repo. (Creating new plugins isn't the aim of the project). Then the actual project starts.
   1.1) We already have (potential) testing environments which are mentioned alongside the plugin.
   1.2) Documentation shouldn't be an issue.
   1.3) This partially invokes maintenance on our plugins, but most of them won't be main ones; and it'll only ensure the maintainability part if we get multiple plugins setup with LSP. (from what I understand here)
2. Same thing would have to be done for vs-code, keeping in mind that this repo is still in it's pre-development stages; in your own words :D
3. Other new plugins would have to be made, the process would have to be repeated for them.

IMO the takeaway is: This can be a project in the future, but it's sort of a different direction and partially overlaps with some of the goals of this specific project at the moment.

[li-boxuan]

LSP Support tutorial for Eclipse Che is not very newbie friendly. This tutorial has some dead links. Anyone interested in it may refer to this tutorial instead.

I'm currently investigating support for vim. This should be easy to integrate with our LS.

[gaocegege]

@li-boxuan

I opened a separate issue for vim integration and please keep going. If you have any question feel free to leave comments in #38.

[gaocegege]

I will take a look at che and add feedback if I get something.