Community
Participate
Working Groups
Created attachment 184451 [details] Patches the IMP run-time to add the new extension point and fixes a null pointer exception for loading quickfix assistants (taken from imp-dev mailing list) I'm using LanguageRegistry.registerLanguage(...) to dynamically extend Eclipse with editors for new languages. The extension points of such languages are implemented by some "multiplexing" instances of the IMP services that dynamically find the right implementation for each editor, based on the language name and some lookup table. These implementations are provided by Rascal programs. So far so good ;-) This all works fine when you're running Eclipse and you don't quit it. Now when I quit Eclipse and start it up again, the editors for those dynamically registered languages might still be there. However, since their language is not registered by an IMP extension point, there is no language registered for those editors and NullPointerExceptions start jumping at you from all parts of the UniversalEditor :-( The question is: where would you add some code that can re-register those languages, just in time before the UniversalEditors that are still open will start complaining about missing languages? I don't think there is a default Eclipse way to do it, and UniversalEditor does not provide a service for it either. I've added an extension point (see patch) that will run a bunch of registered Runnables when the LanguageRegistry will have been initialized. This guarantees that when findLanguage is called, an already existing editor will have had the change to have its language registered for it dynamically.
[ Ooh, the meta-ness of this is giving me chills. :-) You want to extend the extension mechanism... ] This sounds entirely reasonable to me. In essence, given that we already support dynamically registering languages, you now need a way to trigger that early enough at startup. Here's my first-cut proposal: Let's create an extension point for the following interface: public interface LanguageRegistrar { public void registerLanguages(LanguageRegistry registry); } This would be called by the LanguageRegistry after the normal registration process is complete. Sound good? ============== BTW, I don't know that the following helps any, but I've recently committed changes to support dynamic language registration when bundles are activated/deactivated. I've been using this as part of my work on resuscitating the source formatting rule editor. The editor can now be run in the same workbench as the rest of IMP! Seems to work pretty well, though I still have to fix a bug or two in some code that asks the PDE for all the defined extensions (installed + workspace-resident).
allright. I'll change my patch to use this interface instead of java.lang.Runnable and commit it.
O BTW, that news about the formatting editor really does sound cool!
One note: LanguageRegistry is all static, so a reference can not be passed in the interface method.
Oh, right, good point about the LanguageRegistry (doh!)... We should probably make the LanguageRegistry non-static anyway...
fixd as suggested above
