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.
I do understand that new editor can get TypeScript
support by means of tsserver. At the same time there are
multiple existing TypeScript plugins for Eclipse and one of them
already uses tsserver:
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
How? Do you know decent C# tools for Eclipse IDE?
It is possible to get support for C# in Eclipse.
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.
And I am absolutely positive that this is not the most
needed feature across current Eclipse user base.
Some Eclipse contributors also have goals that go beyond just the
Eclipse IDE ;)
I understand that others (non-Eclipse) can benefit from
converting JDT to code server. But for Eclipse IDE and JDT
itself it will hardly give any benefits.
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.
I mean that all understand that Microsoft will not
contribute any features to Eclipse or JDT.
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.
Why would they help to develop any free Java based project
after they killed robovm and do not support Java in their
"Azure Functions" (just for reference PHP and Bash are
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.
Eclipse already has plugins for all major languages
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.
so rewriting them to be able to expose same functionality
via code server by definition will not add anything few to
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
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.
At the same time there are requests for Eclipse core
features which are not addressed for years. For example, even
now after more that 2 years after Java 8 was officially
released (not counting time it was in developement) Eclipse
content assist functionality still has no support for lambda
_expression_ completions. Other example is that https://www.eclipsecon.org/na2016/session/faster-index-java-or-cdt-pays-its-debt-jdt
is developed outside of Eclipse. Eclipse Android tools are not
very actively maintained.
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.
Don't get me wrong. It's open source project and you decide
what to implement. And I really don't want to offend anyone. I
am just struggling to understand what this can give to average
Eclipse IDE user. And it is quite sad for me to realize there
is a chance that Eclipse can get yet another TypeScript editor
or even C# support before having that (reported in 2014) issue
with lambda auto completion support addressed.
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.