Languages Tools Factorization
Eclipse is the host of various programming languages tools (JDT, CDT, JSDT/VJET, AJDT, PDT... at Eclipse.org; Ceylon-IDE, Groovy-Eclipse, Scala-IDE, Counterclockwise... outside of Eclipse.org). Most of these tools have been sharing the same features but not necessary the same code because of the lack of factorization on this topic.
The goal is to find out which pieces are implemented by most Language Development Tool, and to implement them in a generic/universal way as part of a LTK-like project or component (or LTK itself). Then, it would be easier to write Tools for new languages by re-using the available bundles, and more mature projects could move towards this new bundles in order to benefit from factorization.
- http://www.eclipse.org/org/langsymp/ (?)
- http://dev.eclipse.org/mhonarc/lists/ide-dev/msg00023.html (2013)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=415563 (2013)
Existing Language Development Tools
This is not meant to be an exhaustive list of all LDTs. It is meant to identify which LDTs are under active development and can serve as examples of the kinds of languages and features we want to support:
- JDT (JVM)
- AJDT (JVM)
- Koneki LDT
- Xtend IDE (JVM)
- Groovy-Eclipse (JVM)
- CeylonIDE (JVM)
- Scala-IDE (JVM)
- Counterclockwise (JVM)
- Object Teams (JVM)
Indexing the code structure to make it efficient to search for types/members. There are two components of this feature:
- Creating indexes: This operation visits a document (or all documents in a project) and extracts relevant keys from inside of them, placing them in a datastore.
- Searching indexes: This operation searches the datastore for documents containing a given key. The result of this operation is a set of documents known to contain the given key. These documents are now suitable for a fine-grained search.
- The datastore itself should be language agnostic. Although, some of the keys placed in the datastore may not be relevant to all languages.
JDT implements a datastore. AJDT and Groovy-Eclipse (and potentially others) implement source code visitors that populate the datastore with language-specific keys. To be more precise, the keys added to the datastore have Java semantics even when they do not represent Java artifacts (eg- pointcuts in AspectJ are stored as method declaration keys). This is problematic.
Xtext has a language agnostic index.
Searches a single document to find a precise location of a semantically rich search pattern. The document is typically a file, archive entry, or a module written in any programming language supported by the current Eclipse IDE.
JDT, AJDT, Groovy-Eclipse (and potentially others).
Idea is to provide a seamless way to navigate to the declaration of a reference across language boundaries. For example, in http://eclipseblog.ostroukhovs.com/2013/11/14/source-editor-worth-70/ , user would like the Open Type dialog to be homogeneous across languages.
Describes an abstract structure of a project so that individual elements can be identified, located, and manipulated. Possibly a prerequisite for refactoring and navigation.
Provide more common features to the code editor. One example is a standard way of providing hover help so that we can show documentation when a user hovers over a symbol. Linux Tools has libHover which does that and may be a good starting point.
Potential new features