If a CSL language is embedded (via EmbeddingProvider) in a document whose top-level language is a non-CSL language (e.g. Java or XML), editor support (syntax highlighting, code completion, etc) is not enabled for the embedded language.
For example, an XML document containing embedded CSS, does not have syntax highlighting or code completion enabled for the embedded CSS.
Two workarounds exist, though neither are easy or complete. The first is to create a placeholder CSL language whose lexer tokenises the entire document as one large token, whose content has the non-CSL host language embedded in it via LanguageHierarchy.embedding() or LanguageProvider.findLanguageEmbedding(). In the case of an XML-based language, this will interfere with XML editing functionality (for example, throwing an exception when trying to format the XML). It is also quite slow. The second workaround is to add CSL Tasks to the non-CSL host language. For example, for a language of mimetype text/mycustomlanguage+xml:
<attr name="instanceOf" stringvalue="org.netbeans.spi.editor.highlighting.HighlightsLayerFactory"/>
<attr name="instanceOf" stringvalue="org.netbeans.modules.parsing.spi.TaskFactory"/>
This workaround cannot enable syntax highlighting for the embedded sections. The reason is that the org.netbeans.modules.csl.editor.semantic.SemanticHighlighterFactory task is only enabled for top level CSL languages, internally iterating through the embedded language sections and adding syntax highlighting for them. For language paths that are either not CSL languages, or not top-level languages, SemanticHighlighterFactory does not create a SemanticHighlighter. To add semantic highlighting using this approach, an alternate SemanticHighlighterFactory needs to be created. Unfortunately, because multiple classes in the org.netbeans.modules.csl.semantic package have package-private methods, to create an SemanticHighlighterFactory, four classes need to be duplicated in the service provider's module (SemanticHighlighter, SequenceElement, GsfSemanticLayer, and HighlightsLayerFactoryImpl).
Step one: To enable non-CSL languages to add editor support for embedded CSL languages via layer.xml (as in the workaround above), the constructor of SemanticHighlighter could be made public, allowing an alternative to SemanticHighlighterFactory to be registered (i.e. one that does create a SemanticHighlighter even though the top-level language is not CSL). This alternative implementation could be enabled for the target non-CSL host language, along with the other CSL TaskFactories.
Step two: Alter the CSL TaskFactories to still create Task instances for Sources with non-CSL top-level languages, and in the case of SemanticHighlighter let it recurse through the embedding hierarchy as they normally do, adding highlights for the embedded languages. For non-CSL top-level languages (like Java and XML), we could only create the Tasks if the source contains embeddings of at least one CSL language, to minimize performance impact.
Created attachment 111689 [details]
Makes constructor of SemanticHighlighter public, to allow alternatives to SemanticHighlighterFactory to be registered more easily
Uploaded patch for proposed solution "step one".
Nesting CSL inside non-CSL language is not supported at all by CSL design. This might change in the next release, so I would keep this as a strong enhancement request rather than defect.
Trying to schedule for 7.4