Suche
Kolumne

Lagebericht Eclipse-IDE: Das neue Editor-Framework

Simon Scholz, Lars Vogel

Oft werden in Eclipse so genannte Texteditoren verwendet, d. h. Editoren, die den Quelltext direkt anzeigen, aber durch Syntax-Highlighting oder Code Completion die Arbeit erleichtern. Traditionell war das Erstellen von neuen oder eigenen Editoren in Eclipse relativ kompliziert. Die Eclipse-Plattform hatte eigentlich nur die Möglichkeit geboten, in existierenden Editoren zusätzliche Klasse zu registrieren, die neue Textbereiche als Hyperlinks identifizieren. Viele Projekte haben daher eigene Frameworks entwickelt, um Editoren erweiterbar zu machen. Projekte wie Eclipse WTP mit den Source-Editoren für XML oder das Mylyn-Projekt für Wiki-Sprachen wie AsciiDoc haben hier gute Lösungen für isolierte Probleme geschaffen.

In einer Zeit, in der neue Sprachen und neue Dateiformate recht schnell entstehen und auch wieder verschwinden, hat dieser Ansatz seine Nachteile. Das Entwickeln von Editoren „eben mal schnell“ war in Eclipse nicht einfach. Entwickler von Red Hat haben dieses Problem erkannt. Eclipse 4.7 wird einen Texteditor haben (Generic Editor), der erweiterbar sein wird. So kann man ihn als Basis für eigene Ergänzungen nutzen. Das macht die Unterstützung von neuen Sprachen und Features signifikant einfacher. Signifikant einfacher? Was soll denn das heißen? Na gut, wir schauen uns einmal ein Beispiel dazu an.

Ein Beispieleditor für Gradle

Wir probieren aus, wie schwer es ist, einen Editor für Gradle zu erstellen, der mindestens Syntax-Highlighting unterstützt. Das Beispiel basiert auf einem Vortrag von Sopot Cela auf der letzten EclipseCon Europe. Dort hat Sopot den Editor live während seines Vortrags programmiert. Als Erstes lädt man sich den neuen Milestone für Eclipse 4.7 herunter. Dann erzeugt man ein neues Plug-in. Da Plug-in-Entwicklung schon in dieser Kolumne beschrieben wurde, gehen wir hier nicht mehr im Detail darauf ein, sondern es werden nur die Besonderheiten für den Editor beschrieben.

Lesen Sie auch: Eclipse-Erweiterungen einfach selbst bauen

Für unseren Gradle-Editor brauchen wir als Erstes einen Content Type, für den man den Editor später registrieren kann. Das geht u. a. über den Extension Point org.eclipse.core.contenttype.contentTypes. Interessant sind hier die file-extension und der base-type.

<extension point="org.eclipse.core.contenttype.contentTypes">
  <content-type
    base-type="org.eclipse.core.runtime.text"
    file-extensions="gradle"
    id="gradleeditorsupport.content-type3"
    name="Gradle"
    priority="normal">
  </content-type>
</extension>

Dann legt man zwei kurze Klassen an. Die folgende Klasse definiert in unserem Beispiel die Schlüsselwörter, die per Syntax-Highlighting hervorgehoben werden sollen (Listing 1).

Listing 1: Klasse für das Syntax-Highlighting
package gradleeditorsupport;

import org.eclipse.jface.text.TextAttribute;
import org.eclipse.jface.text.rules.IToken;
import org.eclipse.jface.text.rules.IWordDetector;
import org.eclipse.jface.text.rules.Token;
import org.eclipse.jface.text.rules.WordRule;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.RGB;
import org.eclipse.swt.widgets.Display;

public class GradleKeywordRule extends WordRule {

  String[] tagWrods = new String[] { "android", "compileSdkVersion", "buildToolsVersion", "defaultConfig", "applicationId", "targetSdkVersion", "applicationId", "versionCode", "minSdkVersion", "versionName", "testInstrumentationRunner", "buildTypes", "release", "dependencies", "androidTestCompile", "minifyEnabled", "proguardFiles", "compile", "testCompile", "apply", "plugin", "launcherArgs" };

  private IToken wordToken = new Token(new TextAttribute(new Color(Display.getCurrent(), new RGB(139,0,139))));

  public GradleKeywordRule() {
    super(new Detector());
    for (String word : tagWrods) {
      this.addWord(word, wordToken);
    }
  }
}

class Detector implements IWordDetector {
  public boolean isWordStart(char c) {
    return Character.isAlphabetic(c);
  }
  public boolean isWordPart(char c) {
    return Character.isAlphabetic(c);
  }
}

Die zweite Klasse ist dann der so genannte PresentationReconciler, der die Darstellung des Texts übernimmt. Hier werden die Schlüsselwörter registriert und es wird u. a. definiert, was ein Kommentar darstellt (Listing 2).

Listing 2: Klasse für die Darstellung des Texts
package gradleeditorsupport;

import org.eclipse.jface.text.IDocument;
import org.eclipse.jface.text.TextAttribute;
import org.eclipse.jface.text.presentation.PresentationReconciler;
import org.eclipse.jface.text.rules.DefaultDamagerRepairer;
import org.eclipse.jface.text.rules.IRule;
import org.eclipse.jface.text.rules.IToken;
import org.eclipse.jface.text.rules.NumberRule;
import org.eclipse.jface.text.rules.PatternRule;
import org.eclipse.jface.text.rules.RuleBasedScanner;
import org.eclipse.jface.text.rules.SingleLineRule;
import org.eclipse.jface.text.rules.Token;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.RGB;
import org.eclipse.swt.widgets.Display;

public class GradlePresentationReconciler extends PresentationReconciler {

  private IToken quoteToken = new Token(new TextAttribute(new Color(Display.getCurrent(), new RGB(139, 69, 19))));
  private IToken numberToken = new Token(new TextAttribute(new Color(Display.getCurrent(), new RGB(0, 0, 255))));
  private IToken commentToken = new Token(new TextAttribute(new Color(Display.getCurrent(), new RGB(0, 100, 0))));

  public GradlePresentationReconciler() {
    RuleBasedScanner scanner = new RuleBasedScanner();

    IRule[] rules=new IRule[5];

    rules[0] = new SingleLineRule("'", "'", quoteToken);
    rules[1] = new SingleLineRule("\"", "\"", quoteToken);
    rules[2] = new NumberRule(numberToken);
    rules[3] = new PatternRule("//", null, commentToken, (char)0, true);
    rules[4] = new GradleKeywordRule();
    
    
    scanner.setRules(rules);
    
    DefaultDamagerRepairer ddr = new DefaultDamagerRepairer(scanner);
    this.setDamager(ddr, IDocument.DEFAULT_CONTENT_TYPE);
    this.setRepairer(ddr, IDocument.DEFAULT_CONTENT_TYPE);
  }

}

Jetzt muss der GradlePresentationReconciler nur noch mit dem Framework über die plugin.xml registriert werden.

<extension point="org.eclipse.ui.genericeditor.presentationReconcilers">
  <presentationReconciler
    class="gradleeditorsupport.GradlePresentationReconciler"
    contentType="gradleeditorsupport.content-type3">
  </presentationReconciler>
</extension>

Startet man eine neue Eclipse-Instanz mit diesem neuen Plug-in und öffnet eine .gradle-Datei via OPEN WITH | GENERIC EDITOR, hat man schon einen Editor mit Syntax-Highlighting (Abb. 1). Das war doch einfach, oder?

scholz_vogel_eclipse_1

Abb. 1: Editor mit Syntax-Highlighting TextMate-Support und Microsofts Language Server Protocol

Unter folgenden Link arbeiten Angelo Zerr und Mickael Istria an der Unterstützung für die populäre TextMate Grammar (TextMate, Bugtracking). Damit würde jede Sprache, die eine TextMate-Beschreibung hat, Syntax-Highlighting in Eclipse unterstützen. Der Plan ist, dass dies ab Eclipse 4.7 in die Eclipse-Downloads integriert wird. Damit ließe sich Eclipse für neue oder noch nicht in Eclipse unterstützte Sprachen nutzen – ähnlich wie Sublime, Atom und Emacs das heute schon können.

Um das Ganze noch einfacher zu machen, arbeiten Istria und Cela auch an der Unterstützung des Microsoft Language Server Protocols für den Generic Editor. Hier hat Microsoft ein JSON-basiertes Kommunikationsprotokoll entwickelt, mit dem Serverkomponenten mit Editoren sprechen können. Die lokal laufende Serverkomponente analysiert die Datei und schickt ein JSON zurück, das das Syntax-Highlighting, die Quick Fixes, die Tooltips und die Code Completion für die Datei liefert.

Lesen Sie auch: Ansible IDE-Vergleich: IntelliJ vs. NetBeans vs. Eclipse

Da Microsoft dieses Protokoll in seinen Tools unterstützt oder unterstützen wird, ist hier breite Unterstützung in den Sprachen entweder schon vorhanden oder in Arbeit. Das Eclipse-JDT-Projekt arbeitet zurzeit an einer Serverkomponente, um die JSON-Daten für einen Java-Editor bereitzustellen. Aber auch andere Sprachen liefern gerade solche Serverkomponenten. Und die Eclipse-Nutzer werden auch von diesen Arbeiten profitieren, um mit Rust, Ruby, Scala oder für andere Sprachen zu entwickeln. Die Arbeiten werden im neuen Eclipse-LSP4E-Projekt durchgeführt.

Fazit

Das Eclipse Editor Framework wird leichtgewichtiger, und es wird einfacher, von anderen Open-Source-Standards zu profitieren. Das sind sicherlich gute Nachrichten für die Eclipse IDE. Es wird immer mehr wiederverwendet, und es ist immer weniger notwendig, die Dinge selbst zu implementieren. Damit können Eclipse-User künftig direkt mit neuen Sprachen arbeiten und müssen nicht mehr ein bis zwei Jahre warten, bis jemand die Features in der IDE nachimplementiert hat.

Geschrieben von
Simon Scholz
Simon Scholz ist Eclipse Platform und e4 Committer. Er entwickelt auch am PDE, und Eclipse Gradle Tooling mit und nutzt seine langjährige Eclipse-RCP- und Plug-in-Erfahrung für Kundenimplementierungen, Eclipse-RCP-Workshops und Schulungen. Zudem hält er regelmäßig Vorträge auf Softwarekonferenzen bzgl. verschiedener Eclipse-Technologien.
Lars Vogel
Lars Vogel
Lars Vogel ist Geschäftsführer der vogella GmbH, die Kunden im Bereich Eclipse, Android und anderen Themen unterstützt. Als Project-Management-Committee-Mitglied, Eclipse-Projektleiter und Committer hilft er dem Eclipse-Projekt. E-Mail: lars.vogel@vogella.com
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.