New rule in color scheme doesn't match what I expected

[ThomSmith]

I would like to ‘reset’ the highlighting of code embedded in strings. So I added the following to Monokai:

<dict>
    <key>name</key>
    <string>Embedded Code Reset</string>
    <key>scope</key>
    <string>string source</string>
    <key>settings</key>
    <dict>
        <key>foreground</key>
        <string>#F8F8F2</string>
    </dict>
</dict>

This works, but now strings inside that code are no longer highlighted. For instance:

"select highlighted, 'a string', contents from myTable"

The text within ‘a string’ has scope:

embedding.cfml  source.cfml.cfscript  string.quoted.double.cfml  source.sql  string.quoted.single.oracle

I would expect the highlighting for string to win because it matches further right than string source does. However, it is colored like string source, not like string. What am I doing wrong?

[jfcherng]

Yeah. That’s how ST works currently. It’s counter-intuitive for me as well. A maybe-related post here.

[ThomSmith]

Is there any workaround? I can’t quite see one that would work in the general case.

[jfcherng]

Does defining a color for string source string works?

[FichteFoll]

This particular situation might be resolved in the future thanks to the clear_scopes directive for syntax definitions.

[Ruby] Support code on same line as heredoc begin token

[mlf]

A scope of ‘string string’ should do just fine (‘nested’ strings).

Gives things like (regular string color being green on white, nested being green on light green):

The relevant part in my color scheme being:

[ThomSmith]

Yes, but only for a fixed depth of nesting.

[ThomSmith]

This particular situation might be resolved in the future thanks to the clear_scopes directive for syntax definitions.

I tried using clear_scopes (took me a while to figure out exactly what it was doing), but I don’t actually want to remove the string scope. The SQL code is in a string – when I removed that scope, it broke pairing of # because that is only available in strings. I could rewrite the pairing conditions as a workaround, but fundamentally it doesn’t seem like the right approach.

clear_scopes seems intended for situations like another I’ve run into, where I want a snippet available in the body of a Javascript object literal but not within an expression inside that literal. Removing the object literal scope seems like exactly the right thing in that case.

A scope of ‘string string’ should do just fine (‘nested’ strings).

Would that work for a scope like source string source string source? I think that source would still win over string string in that case.

[FichteFoll]

I didn’t know you were talking about SQL strings. I thought this was about interpolated strings.

I don’t have a set opinion on how I would stylize SQL queries in strings.

[mlf]

Would that work for a scope like source string source string source? I think that source would still win over string string in that case.

‘source string source string source’ does not work (because your nested ‘a string’ is not in such a scope). But ‘source string source string’ or ‘string source string’ also works.