Like this question, I work on documents with HTML and CSS that are inside <![CDATA[ tags.
Unless I manually comment out those tags, anything inside them is treated by ST as plain text, no colour format, no autocomplete, etc.
Can I tell ST to treat <![CDATA[ as if they were commented out? As one possible way to allow me to not have to keep manually commenting out-in-out the <![CDATA[ each time I edit and check on a browser?
Thanks.
Do you spend a significant amount of time in these files? If so, you might want to make a “toy” syntax definition that glues the XML and HTML syntaxes together where <![CDATA[ is encountered.
Yes I do. Intrigued. I’ll go play to see if I can work out how to do this. Thanks!!
Is it about XML files embedding HTML within CDATA tags?
Just ignoring CDATA in a XML wouldn’t automatically cause highlighting of HTML and CSS at the same time.
Simple HTML might work, even though XML might fail on some HTML specific sutff, but highlighting CSS directly within CDATA tags at the same time, might need some heuristics to check for the syntax to use.
Proposal:
Packages/User/XML (with HTML).sublime-syntax
%YAML 1.2
---
name: XML (with HTML)
scope: text.xml.html
version: 2
extends: Packages/XML/XML.sublime-syntax
contexts:
cdata-content:
- meta_include_prototype: false
- meta_content_scope: text.html.embedded.xml
- match: ']]>'
scope: punctuation.definition.tag.end.xml
pop: 1
- include: scope:text.html.basic
Oh wow @deathaxe, that looks like it is well on the way to solving this.
Aside: I don’t use CSS between CDATA tags much.
But I do do use HTML a lot:
<![CDATA[
<p>lots</p>
<p>of lines</p>
<p>of html, almost every day</p>
]]>
With your .sublime-syntax file, code syntax colours all now show correctly. BIG step forward.
Looks like a/some packages don’t understand though, e.g. with the cursor in a <p> using the (Emmet?) key-combo to select tag pairs, rather than the </p> getting a 2nd cursor, the pair of cursors move to the opening and closing tags that precede the CDATA tag – perhaps it was important that I had noted the actual line in full:
<ALSO><![CDATA[
<p>lots</p>
<p>of lines</p>
<p>of html</p>
]]></ALSO>
So the Emmet issue sees the pair of cursors jump to the <ALSO> / </ALSO> tags.
If I can get “full HTML operation”, just like when <ALSO><![CDATA[ is commented out, that would be amazing. But I have no expectations here and thank you again, very much for the big step forward.
I already removed meta.tag.sgml.cdata as it confused ST’s builtin close_tag command.
The only other chance I see is to also clear the xml main scope and any other evidence of html being embedded.
cdata-content:
- clear_scopes: true
- meta_include_prototype: false
- meta_content_scope: text.html.basic
- match: ']]>'
scope: punctuation.definition.tag.end.xml
pop: 1
- include: scope:text.html.basic
Emmet may hower do its own parsing of surrounding context, which would cause this change not to take effect.
Understood; looks like it must be Emmet doing its own parsing as it still goes to the two parent tags above the CDATA.
I can see this is a complex area!
Thanks again tho’, very grateful for the help.
TL;DR: disable Emmet (if like me you are just using it for selecting pairs of tags), use double Ctrl+d instead, and then this custom syntax will allow natural HTML editing within CDATA tags.
Stumbled upon this thread and I am delighted to discover I can disable Emmet (and soon remove once I’ve tested more) and still (with the double Ctrl+d) edit opening and closing tag pairs together.
So so far, without Emmet, it looks like this syntax finally solves my issue with editing HTML within CDATA tags.
Posting this to say brilliant!, thank you again @deathaxe, and also in case it helps anyone else in the future.