Developer information

EclipseShell @ Sourceforge Blog/News (RSS)

Developers and EclipseShell

If you want to help out with EclipseShell, there are several areas where you can start.

Add support for a new dynamic language

EclipseShell was designed to be extensible, so you can add a new language support easily by writing a new Eclipse plugin. I’ll add some further documentation for this, but here are a few basic steps that you can already follow. First look at one of the existing language providers by looking at their code in CVS. Here is the EclipseShell CVS information page a Sourceforge I can recommend the Javascript or Rhino provider, because they are still very simple but show all necessary concepts.

After that, adding support for a language has these basic steps:

• Extend the net.sf.eclipseshell.EclipseShellPlugin.executionEnvironmentProvider extension point
  • Again, see what existing language providers do
  • One hint: the delimiter and delimiterRegex attributes are needed to allow storing command history files. Basically, a delimiter should be a comment in the language, so they are ignored by the interpreter. These delimiters seperate code regions, so they can be reconstructed when the command history is reopened. The delimiterRegex is a Regex (using the java.util Regex syntax) for recognizing these delimiters.
  • the supportedRunModes attribute are shows which modes are available. You can see these in the EclipseShell drop down menu: each language has a cascading submenu showing these modes. There’s a loose convention; “eclipse” means that the launched interpreter runs in the Eclipse JVM process, “externalDebug” means that a new JVM or other process will be started. Note: how this is done is defined by you in the IExecutionEnvironmentProvider or IExecutionEnvironment classes.

• Create a language Provider, a class implementing net.sf.eclipseshell.extensions.IExecutionEnvironmentProvider
  • Think of this as a Factory, that creates EclipseShell IExecutionEnvironments. This allows you to create different types of IExecutionEnvironments for different execution modes, files, etc.

• Create an EclipseShell ExecutionEnvironment
  • This represents the instance of a launched interpreter.
  • The job of this is mainly in the execute(String) method. This will be called by the EclipseShell editor. CAUTION: To allow long running code to be executed in EclipseShell editor, this method will be called in a non-GUI thread!
  • You can provide AutoComplete support by returning an org.eclipse.jface.text.contentassist.IContentAssistProcessor object in the getContentAssistProcessor(IProject proj) method. This will then be shown when the user requests AutoComplete. CAUTION: be very careful in the work you do in the completion process, as this is called on the GUI Event dispatching thread; if you block in this code, the whole GUI will be blocked!
  • You can provide TextHovers for the EclipseShell editor by returning a org.eclipse.jface.text.ITextHover object in the getTextHover(IProject proj) method.
  • You can customize syntax highlighting with the getDamagerAndRepairer(), if you return a tuple (as Object[]) of {IPresentationDamager, IPresentationRepairer} objects.
  • If you also implement net.sf.eclipseshell.extensions.IJavaRuntimeHandler you’ll get a handle to information about the Java project this EclipseShell editor was started in. This allows you to get JavaDoc information, Java type information, etc.

Provide information for an existing language/interpreter

I currently provide the languages

• JRuby
• Beanshell
• Ruby (remote controlled irb)
• Javascript (Mozilla Rhino) I provide AutoComplete at various levels, and some TextHovers for native Ruby (using ri lookup). If you know more about these interpreters and see how I could improve AutoComplete or provide information for TextHovers or you want to provide better syntax highlighting, check the source for these language providers and send some information to the mailing list. If you’re really enthusiastic (or annoyed by a bug), feel free to send patches.