Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Code editors in the Eclipse (IDE)

Sounds like we┬╣re heading in multiple directions. I have no horse in this
race, but the first one that gives me a TSX editor (JSX for Typescript)
wins :).

On 2016-06-15, 7:42 AM, "ide-dev-bounces@xxxxxxxxxxx on behalf of Tom
Schindl" <ide-dev-bounces@xxxxxxxxxxx on behalf of
tom.schindl@xxxxxxxxxxxxxxx> wrote:

>*Disclaimer: This post is going to be long I hope you follow until the
>There seems to be a lot of momentum to make simple code-editors in
>Eclipse possible.
>As I've been working since some time on this topic I'd like to share
>with you my take on this (Max already mentioned my name in some of the
>*Let's start with a requirements*
>Simple requirements
>The first and most important things needed are:
>- syntax highlight (lexical!)
>- block detection (for curly brace language this means matching
>  {},[],() pairs) used for highlighting and code-folding (although I
>  don't really see code-folding as an important feature at all)
>The important thing for those 2 features is:
>a) they must be fast
>b) they must be fast
>This means there's no need to build an AST hence no language-server,
>compiler, ...
>There are solutions available for that already:
>- Angelo has TextMate support
>- LiClipse has TextMate support & its custom spec format
>- e(fx)clipse has its own format (who misses code folding as of today)
>Although I'm not against having TextMate I repeat that the most
>important thing for lexical highlighting is speed hence I'm not sure the
>TextMate route is the best way.
>Having it as a fall back strategy if not better format is available is
>ok but for maximum performance we need something who aligns 100% to the
>way Eclipse-Text is working.
>Complex requirements
>Once we have something that matches the simple requirements we can work
>integrating the more complex ones who are (once more in order of
>- Auto-Complete
>- Error-Reporting
>- Documentation Hover
>- Context-Information
>- Code navigation
>- Semantic-Highlighting (there might be languages like DSLs where
>  semantic highlighting is even more import than anything else eg CSS)
>Most of those can be made possible using Language-Servers and their
>protocols [1,2] (although I would not directly built in the support for
>a specific protocol into Eclipse).
>Even more Complex requirements
>- Connection to Debuggers, ... - no idea about that yet
>*How to implement*
>Bug 496114 suggest to implement this support by making TextEditor
>smarter and Bug 496119 suggest to implement a PoC based on JSDT.
>Doing a PoC using JSDT is ok, although I'm uncertain what one would
>learn from that beside that: Yes you can implement ContentAssist based
>on it and yes you can do Error-Markers but that should not be a suprise
>given that there are PoC demostrating this even at the lower-level APIs
>of SourceViewer.
>On to bug 496114. I would stay away of doing the implementation on
>TextEditor, it carries so much history with it and what makes it for me
>even less attractive is that it is so tightly bound to the Eclipse IDE
>and the compat layer so that using it for custom IDEs (who are getting
>more on more built on pure e4) a none-starter.
>Finally implementing all this directly into TextEditor will most likely
>not work because one will interfere with subclasses like JDT, Xtext, ...
>and IIRC the editor uses SourceViewer as now (subclasses like JDT
>overwrite that) and eg for Folding you need to have a ProjectionViewer.
>Leave it alone and start with a clean code base who takes the lessons
>learned since then and implement a new one:
>* who uses services
>* who uses dependency injection
>* who can run in
>  - the Eclipse IDE
>  - an e4 application with core.resources
>  - an e4 application without core.resources
>  - an plain java-application without core.resources
>  - an e4 application with SWT
>  - an e4 application with *fill-in-your-favorite*
>* don't use preferences to carry colors, they should come from a theme
>Now to finish up: Can this be done, is there a PoC.
>Yes there is:
>It uses the Dart-Language-Server and not the M$-Language-ServerAPI
>because this work is older than a year but the concept is so so similar
>that you can be sure it will work with it.
>Beside the few SWT bits in code-swt project the APIs are all coming from
>the e(fx)clipse project (who is an project) and unlike its
>name we have designed and bundled things in a way that they can run
>without JavaFX and Eclipse.
>We have services for almost all of the above features and split them
>*always* in 2 parts:
>- core-service who is reponsible to provide the data
>- ui-service / UI-Technology who is responsible to present the data
>What type of services do we have so far:
>* Lexical highligthing
>- Document Partitioning == IPartitionTokenScanner
>- Damaging / Repairing == IPresentationReconciler
>=> we have a concrete implementation for them based upon our
>   declarative highlighting language but if there's a service with a
>   higher-ranking this would win the game available for JavaFX and SWT
>* Auto-Complete
>- Core-Service OSS implementation for Dart & Typescript
>- (JavaFX only) UI-Service OSS implementation for Dart & Typescript
>* Error-Marker
>- Core-Service OSS implementation for Dart & Typescript
>- (JavaFX only) UI-Service OSS implementation for Dart
>* Code-Navigation
>- Core-Service OSS implementation for Dart & Typescript
>- UI implememtation for JavaFX-Editor
>* Hover
>- Core-Service OSS implementation for Dart & Typescript
>- (JavaFX only) UI-Service OSS implementation for Dart & Typescript
>* Pair-Matching
>- Core-Service OSS implementation for Curly-Brace languages
>- (JavaFX only) UI-Service OSS implementation for Dart & Typescript
>Finally what languages have we already look at and we know we can
>implement with our APIs and their headless servers:
>- Dart
>- Typescript
>- Java (we built a small headless-server with JDT-Core)
>- JavaScript (we leverage LanguageService API)
>- Rust
>- Go
>Thomas Schindl, CTO
> EDV Systemhaus GmbH
>Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
>Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>ide-dev mailing list
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit

Back to the top