editorHighlighterProvider extension point not doing anything?

Dear All,

I am trying to implement a syntax highlighter that scans the whole file at every change, because my use case pretty much percludes using a simple lexer [1]. My best guess of how to do this would be to extend the class LexerEditorHighlighter, overwritting the documentChanged method as such:

public MyEditorHighlighter(EditorColorsScheme scheme, Project project, VirtualFile file) {
    super(new MySyntaxHighlighter(), scheme);
}
 
public void documentChanged(DocumentEvent e) {
    synchronized (this) {
        final Document document = e.getDocument();
        
setText(document.getCharsSequence());
    
}
}



and then define an EditorHighlighterProvider with

public EditorHighlighter getEditorHighlighter(@Nullable Project project,
                                              @NotNull
FileType fileType, @Nullable VirtualFile virtualFile,
                                              @NotNull
EditorColorsScheme colors) {
    System.out.println("Highlighter Provider Called!");
    return new
MyEditorHighlighter(colors, project, virtualFile);
}


and finally register it with the editorHighlighterProvider extension point:

 
     <editorHighlighterProvider filetype="MyFileType" implementationClass="my.path.MyEditorHighlighterProvider"/>



But, when I do this, the EditorHighlighterProvider never gets called! (the line System.out.println("Highlighter Provider Called!"); above never gets called)

Shouldn't this at least call the getEditorHighlighter function once at some point? Am I missing something here?


[1] The reason for doing this is that I am getting my syntax information directly from the AST computed by a fairly sophisticated compiler (not written in Java), whose lexing behavior I cannot possibly hope to reproduce inside jetbrains; think of Common Lisp with its reader macros: even reproducing the lisp reader would require implementing a complete lisp interpreter; so it is with latex, and other languages with sophisticated reading behavior.

4 comments
Comment actions Permalink

If your file does not implement LanguageFileType, you need to use the <syntaxHighlighter> extension point instead.

Note that the editor highlighting is invoked synchronously, in the event dispatch thread, after every character typed. It's very unlikely that sending the entire contents of the file to an external compiler will result in adequate performance.

0
Comment actions Permalink

But it does, I have extended LanguageFileType and FileTypeFactory into my own classes, and registered them in the fileTypeFactory extension point, as explained here: https://confluence.jetbrains.com/display/IntelliJIDEA/Language+and+File+Type

I understand the performance concern, and I will eventually address it.

Alternatively to implement this via the lexer, is there a way of having the _parser_ color the text? (I am assuming the parser isn't called quite as often; I would be OK with having the text temporarily miscolored)

Because my use case is a bit unusual, I can't seem to figure out how by reading the documentation.

0
Comment actions Permalink

You can color the text using an Annotator, or by implementing a custom HighlightingPass. Both of these will be called as part of daemon code highlighting, which starts after 300 ms of user inactivity, and will run in a background thread.

0
Comment actions Permalink

Thank you, the annotator solution seems to be working just fine.

0

Please sign in to leave a comment.