| Re: [ide-dev] TM4E (not) in EPP |
On 21 Mar 2017, at 18:08, Mickael Istria wrote:
On 03/21/2017 05:48 PM, Max Rydahl Andersen wrote:
(I still hope the textmate support becomes into EPP packages sooner rather than later ;)
Having textmate support in EPP doesn't give much value to end-users, just like having language-server protocol support.
okey, then I think eclipse IDE has set it self up to fail. The statement above is just not the right approach when you look at one of the consistently top plugin on eclipse marketplace is Eclipse Color theme (https://marketplace.eclipse.org/content/eclipse-color-theme) and that every other editor winning in the tool landscape today has some support like this.
The value will come to users once there are some downstream Eclipse.org projects relying on those and shipping some textmate grammars and concrete language server integrations for new languages.
This is just wrong and and it is taking the same approach that have already caused eclipse to loose grounds: expecting users to be okey to let it require multiple man months/years for a plugin to become available for a language.
There are already good examples using both TM4E and LSP4E (for PHP, C#) or only one of those (CSS, HTML+CSS+JS), but they're currently still experiments, not at Eclipse.org so nor part of EPP. We'll probably investigate using VSCode language server as an alternative to WTP HTML/JS/CSS editors soon, but it's not an immediate plan for anyone AFAIK.
I'm personally trying to improve aCute (C# relying on TM4E and LSP4E). It is already available on Marketplace and I would like it to work decently without big quirks for Oxygen release.
again, this is about extended language protocols and content assist - I'm talking about the basics of syntax highlighting and being able to easily extend the IDE.
If the textmate and base LPS is not in platform or in EPP it will just result in conflicts of which LPS runtime to install and years of additional months of bad install experience.