Eclipse Plugins

Screen Shot 2014-09-19 at 20.02.45

This is a code focused post for people who arrive here from Google – it’s a post I would have found extremely useful a couple of years ago. The next half dozen post in the queue are very disability-focused.

tl;dr you can get the code from github here.

Part of my work on the PLanCompS project recently was in building plugins.

When I started out I found there was relatively little in the way of useful stuff for me to learn from.   There were forum’s that didn’t answer questions – stackExchange sites that made an attempt but I never quite worked out, after months and months exactly how anything was really working under the hood.  And I found the only available book on the subject very very poor indeed.  

Almost all the work I produced was from copying and pasting code samples and trying them in effectively random permutations until something worked – the sort of coding I though I’d left behind at undergraduate level.  

What I really really needed, was just the odd example project.  Just a zip file that I could download, import, run – see the behaviour and *then* play with.  And now that I’ve got much further with Eclipse plugins – I can build such things for other people.

So this (github link) is a stripped down editor – all it does is performed syntax colouring on files with the extension *.example.  It highlights comments in two formats – either c-style “//” or within special tokens “(* like this *)”.  It also highlights a range of other tokens as will be clear in the code.  I should say that I’m nobody’s idea of a commercial coder, the code is ugly all over even to my rought-and-ready eyes – but it’s simple and it runs and people can edit it.

The payload file for syntax colouring is ExampleRuleScanner, and the particular lines to play with might be these:

rules.add(new EndOfLineRule("//", commentToken));
     rules.add(new EndOfLineRule("//", commentToken));
    rules.add(new EndOfLineRule("#", commentToken));

    rules.add(new WordPatternRule(iWordDetector, "foo", "", keyword));
    rules.add(new WordPatternRule(iWordDetector, "bar", "", keyword));
    rules.add(new WordPatternRule(iWordDetector, "`", "", backquoteToken));

    rules.add(new SingleLineRule("'", "'", stringToken));
    rules.add(new SingleLineRule("\"", "\"", darkStringToken));

    rules.add(new SingleLineRule("(*", "*)", commentToken));

Have a play! comment out things, follow the links and play – but this is exactly what I was looking for some time ago. 

To tell you a little bit more about each of the files in the project: 

ExampleEditor is the one that the Editor extension point points to – it’s the main class for editors – you’ll notice that it extends the textEditor class.  From your point of view there is relatively going on in the class itself – the main line is actually: 

 setSourceViewerConfiguration(new ExampleSourceViewerConfig(this));

…and almost all the work happens in the ExampleSourceViewerConfig.  Not just for syntax colouring either – when you are setting up things like formatting, hovering, setting and using markers and so on – all that will be put in ExampleSourceViewerConfig by means of methods overriding the superclass. 

In this case the code that allows the syntax colouring in ExampleRuleScanner to connect with the editor is in two places – first: 

 

public ExampleRuleScanner getTagScanner() {
    if (scanner == null) {
      scanner = new ExampleRuleScanner();
      scanner.setDefaultReturnToken(new Token(new TextAttribute(DEFAULT_TAG_COLOR)));
    }
    return scanner;
  }

and secondly:

  public IPresentationReconciler getPresentationReconciler(ISourceViewer sourceViewer) {
    PresentationReconciler reconciler = new PresentationReconciler();
    DefaultDamagerRepairer dr = new DefaultDamagerRepairer(getTagScanner());
    reconciler.setDamager(dr, IDocument.DEFAULT_CONTENT_TYPE);
    reconciler.setRepairer(dr, IDocument.DEFAULT_CONTENT_TYPE);
    return reconciler;
  }

(both in ExampleSourceViewerConfig) 

The other class in the package, ExampleFormattingStratergy isn’t actually necessary for syntax colouring – it’s left there so that you can extend to formatting if you like.  If you wish you can fill in the following method: 

@Override
  public String format(String content, boolean isLineStart, String indentation, int[] positions) {

    //your code here
      return content;
   }


 

In the very naive case – all you have to do is to take the string coming in, adjust the whitespace and return it.  Unfortunately one of the small surprises about formatting for your editor is that the triggering isn’t implicit – the normal Java shortcuts only work in the java editor – you’ll have to set up your own trigger – either a binding, a menu or a button.  Entirely up to you.  I did however leave a method in the ExampleEditor file for you to trigger for this: 

  public void reformat() {
    SourceViewer sourceViewer = (SourceViewer) getSourceViewer();
    sourceViewer.doOperation(ISourceViewer.FORMAT);
  }

Leave a Reply