Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Next Meeting?

On 25 Mar 2016, at 11:55, Mickael Istria wrote:

Hi Tom, all,

Just to highlight that Platform can already support some items in this approach, at low enough level (Text, Resources). Many interesting extensions are also available in JDT, but they're only in JDT and weren't made more generic so far.
On the ide-dev, this has also been a topic lately, to define an abstraction of a text editor that would allow the features you mentioned. However, my impression is that this is all a set of individual initiatives that are currently failing at being gathered. And DLTK also provides some generic extensions such as pluggable hovers, but I'm not sure what it cost for a new language to be able to use DLTK.

All of these are examples of doing the extension on "top" of existing parts - they are not in the platform thus they are not intended for reuse (JDT) nor are they available for platform and their extenders to use (i.e. DLTK is too far way).

It is this approach that IMO are a failure or at least a weakness in Eclipse ecosystem. The fact that for a plugin provider having to provide a full silo of language specific editor, builders, validators, etc. is not normal for other IDE's/text editors.

I think it is time the platform starts becoming an actual platform for an IDE and not only a platform for RCP applications.

/max

On 03/25/2016 10:25 AM, Tom Schindl wrote:

  • Lexical-Syntax-Hightlighting (this is the only service we expect to runside the same VM) but is not implemented as a set of Java-Classes but loaded from a textual configuration file (no we don't use textmates format but could implement that as well!)

See https://github.com/angelozerr/textmate.java . Although not complete, it's already a good working 1st iteration, I suggested Angelo on the wtp-dev mailing-list to bring this into Eclipse.org, for example inside the org.eclipse.e4.ui incubator for a start.

  • Annotation-Support (Errors, Warnings,...)

The Platform API already allows this easily. Think about how Findbugs can annotate classes, or even add error markers. "Binding" such as service is mostly a matter of running the analysis tools (in any way you want) and getting the results to create markers where it makes sense.
One step further would be to have all code-related tools standardized on some IO, formats, protocol...so the execution of the tools and conversion of output to markers could be easily factorized; but I don't imagine this happening, and the current way to plug builders already allows to interact properly enough with such "annotation providers".

What we are looking at next is a protocol / message format we could
define allowing us to unify the communication with all those backends.

I wrote my comment above before I read that ;)

I've done a PoC for Max some weeks ago and we published the code at
github - https://github.com/BestSolution-at/code-swt - the PoC only
demonstrates auto-complete!

So is this something you could contribute to Platform/Text?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria


eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

/max
http://about.me/maxandersen


Back to the top