Community
Participate
Working Groups
The "New Language" wizard creates a plugin activator class that hard-wires the language ID to be the one provided in the corresponding wizard field. Instead, it should probably access the "language" attribute of the plugin's languageDescriptor extension (as LPGRuntimePlugin does). This way, the IDE developer can't break the connection between the literal string in the plugin activator class and the extension definition.
This is easy enough to do, but the rest of the framework doesn't seem entirely robust with respect to changes of the language name as represented in the language descriptor. I haven't investigated this thoroughly, but I created a language and parser and then changed the language name in the language descriptor. When I then tried to open a file, I got a breakdown in the language service manager due to a failure to instantiate the parse controller (partial trace below). I'm not sure if this would be easy or difficult to fix, or whether there might not be other problems. Anyway, it raises the question, do we really want to be able to accommodate this degree of flexibility? (Which may raise more questions, e.g., what about the possibility of changing other information in the language descriptor?) java.lang.Error: Unable to instantiate parser for tmpFive; parser-related services will be disabled. at org.eclipse.imp.core.ErrorHandler.reportError(ErrorHandler.java:72) at org.eclipse.imp.core.ErrorHandler.reportError(ErrorHandler.java:62) at org.eclipse.imp.core.ErrorHandler.reportError(ErrorHandler.java:56) at org.eclipse.imp.editor.LanguageServiceManager.initialize(LanguageServiceManager.java:127) at org.eclipse.imp.editor.UniversalEditor.createPartControl(UniversalEditor.java:575) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:428) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:594)
