deathaxe

Hmm. The idea about a quick panel is not too bad. We already have a [SQL (for Ruby).sublime-syntax](https://github.com/sublimehq/Packages/blob/master/Ruby/Embeddings/SQL%20(for%20Ruby).sublime-syntax) which is derived from SQL.sublime-syntax. It should be easy to write a...

Must be a quite old PHP syntax then. Both ST4126 and ST4143 render it well, without `string` scope.  EDIT: It's common practice to clear string scope within interpolation or...

C family needs definitly a rewrite.

Various syntaxes use `support` scopes to add special highlighting to functions which ship with standard libraries. If the question is why C++ uses `C99`, that's because C and C++ share...

This scope naming change has been made by intent to get inline with how JSON keys are scoped for years now.

See https://github.com/sublimehq/sublime_text/issues/3590 for built-in color schemes, which has lasted for years as well. The point is, what you see in YAML is "state of the art" in JSON for years.

There's also the following statement about it: https://discord.com/channels/280102180189634562/280102180189634562/956253218034315304

https://github.com/sublimehq/Packages/issues/3531 contains some discussion about `source` vs. `text` and why the one or the other may (or may not?) be more suitable for some of the file types - mainly...

Maybe we should keep going with `text.tex. ...` main scope for compatibility reasons with existing color schemes.

It's your color scheme, which needs to be tweaked. Syntax definition won't be reverted. YAML applies the same scopes to keys as JSON has done for ages. Everyone how complains...