|Re: [ide-dev] Benefits of integration with code server and new generic editor for average Eclipse user|
On 06/30/2016 01:04 PM, Serhiy wrote:
This plugin is somehow a lesson to learn. Client-server is a very good approach to developing dev tools. The idea now is to make it easier to consume consistently inside Eclipse IDE rather than expecting developers to repeat the same work over and over again.
TypeScript editor inherit from the JSDT editors, which requires a lot of other plugins to work and that provide many useful extensions. One of the current goals from Eclipse IDE point-of-view is to provide this extensibility in a lower layer that anyone could more easily reuse without depending the the JSDT editor stack.
The work of making an editor generic and extensible enough was already done in WebTools SSE editors. We're trying to move it to Platform.
How? Do you know decent C# tools for Eclipse IDE?
Some of Eclipse contributors have goals that go beyond the current Eclipse user base. The current user base isn't necessarily what drives all of us.
Some Eclipse contributors also have goals that go beyond just the Eclipse IDE ;)
Never say never. I guess a couple of years ago, someone wrote "Microsoft will never contribute .NET under MIT license". See where we are now.
Those proposals regarding generic editors and language services are not meant to attract more help from anyone in particular. They're mostly meant to provide a faster and factorized way to develop features in all IDEs/editors at once.
With or without Microsoft contributing to Eclipse IDE or JDT directly, the Eclipse IDE can take advantage of the proposed approach of Language Services.
correction: all *current* major languages and file formats. And even so, some major languages of the software industry are still missing good support. We cannot say the current state is good for everything and will remain forever.
There is no plan to rewrite anything AFAIK. The proposals so far are about supporting a new editor/set of services to implement support for new features.
Imagine tomorrow, someone contributes an awesome language server for Go; with an unbeatable completion. Then if we already have the framework to consume it, this can be adopted trivially and Eclipse IDE can take advantage of it ASAP. If we're not ready for it, then all competitors will adopt it, they will have a critical advantage on Eclipse IDE, Eclipse IDE will loose users.
Remember algorithmic: Greedy decisions are usually not the optimal one. Focusing only on the current state without vision may lead to irrelevancy.
Every contributor is free to work on what is the most important for them. So far, it seems like those issues are not top-priority of any contributor according to their vision of the IDE.
However, there are programs by the Eclipse Foundation and some member organization that basically allows one to "buy a feature" by a regular development contract. If someone is willing to pay for that, they'll probably find some contributors to do it...
IMO, there are much more users not using Eclipse IDE because of average TypeScript support or non-existing C# support than because of those missing completions on lambdas.
Contributors cannot be in every fight at once. This generic editor and language server seems to be the fight many contributors are interested in winning now. IMO, it's a good tactical choice, but your mileage may vary, and you and all other contributors are free to work on other topics.