This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 203309 - CSL embedding does not work in non-CSL languages
Summary: CSL embedding does not work in non-CSL languages
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: CSL (API & infrastructure) (show other bugs)
Version: 7.1
Hardware: Macintosh Mac OS X
: P2 normal (vote)
Assignee: Svata Dedic
URL:
Keywords: PLAN
Depends on:
Blocks: 202736
  Show dependency tree
 
Reported: 2011-10-07 14:55 UTC by dbell
Modified: 2013-04-25 12:20 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Makes constructor of SemanticHighlighter public, to allow alternatives to SemanticHighlighterFactory to be registered more easily (628 bytes, patch)
2011-10-08 06:00 UTC, dbell
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description dbell 2011-10-07 14:55:43 UTC
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.

Workarounds:
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:

    <folder name="Editors">
        <folder name="text">
            <folder name="mycustomlanguage+xml">
                <file name="org-netbeans-modules-csl-editor-semantic-HighlightsLayerFactoryImpl.instance">
                    <attr name="instanceOf" stringvalue="org.netbeans.spi.editor.highlighting.HighlightsLayerFactory"/>
                </file>
                <file name="org-netbeans-modules-csl-editor-semantic-MarkOccurrencesHighlighterFactory.instance">
                    <attr name="instanceOf" stringvalue="org.netbeans.modules.parsing.spi.TaskFactory"/>
                </file>
                <folder name="CompletionProviders">
                    <file name="org-netbeans-modules-csl-editor-completion-GsfCompletionProvider.instance"/>
                </folder>
            </folder>
        </folder>
    </folder>

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).


Proposed Solution:
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.
Comment 1 dbell 2011-10-08 06:00:58 UTC
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".
Comment 2 Svata Dedic 2011-10-18 16:13:10 UTC
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.
Comment 3 Svata Dedic 2012-12-11 20:34:44 UTC
Trying to schedule for 7.4