Often when opening a file that is to be handled by Spoofax, syntax coloring is not applied. The file is parsed and analyzed however. (Clearing all markers in problem view and opening the file does recreate the markers if syntax coloring fails. Tested both for parse error markers and markers from semantic analysis.)

Typing one character restores syntax coloring.

I didn’t see it happen yet for the (deployed) Stratego or SDF editors. I did see it happen both for my big language and for a small EntityLang derivative.

It appears to be related in some way to the files (size?) as a file on which it fails to apply syntax coloring one time, generally (but not always) fails again the next time I open it, and similarly if it does apply syntax coloring.

It appears to happen less the bigger the file, but I’m not sure the evidence for that is really statistically significant :)

There’s nothing in console or error log.

Observed in r22023 nightly, r22044 nightly, r22070 from SVN.

Submitted by Tobi Vollebregt on 17 February 2011 at 16:12

I haven’t seen this one yet. Any idea on how to reproduce it? It happens when opening small files? Was the language loaded then, or does the IDE still have to load it?

Any idea on how to reproduce it?

I can reproduce it by creating a new project [tried in a new workspace even], naming it EntityLang and then waiting for the wizard to finish. The one time I tried this the example.ent opened by the wizard did not have syntax coloring.

After eclipse restart and repeatedly opening example.ent it appears it’s really random; I think about 70% of the time the coloring won’t be applied, and 30% of the time it will.

Does not happen with deployed plugins though. (Not seen it yet with Stratego/SDF/ESV editors…)

It happens when opening small files?

Read: I have not seen it happen yet with big files. With small files it appears to be random.

Was the language loaded then, or does the IDE still have to load it?

Was loaded. (in the case of repeatedly opening/closing example.ent)

Given the randomness I fear it must be a threading issue somewhere that may or may not be reproducable on a slightly faster/slower system/different JVM/etc….

Thanks, that allowed me to reproduce it. There was a (mostly harmless) race condition: only the UI thread is allowed to determine the current editor that corresponds to the parser, and it didn’t do that yet in this case. I worked around this in r22083 by simply rescheduling the parser in case the editor is not known yet.