Syntax: Support {{variables}} in embed arguments

deathaxe commented 3 years ago

Problem description

If a templating syntax (ASP, JSP, PHP) extends HTML.sublime-syntax in order to support <%...%> tags in any situation, it may need to create intermediate CSS (for JSP).sublime-syntax, ... syntax definitions, with the tag contexts included into prototype.

The goal is to avoid with_prototype and make correct use of embed.

The main syntax HTML (JSP).sublime-syntax needs an easy way to replace the original CSS by the modified CSS (for JSP).

The current solution is to copy all contexts which embed CSS from HTML.sublime-syntax and replace the scope name. That's a bit cumbersome and causes quite a number of duplicated contexts.

see: https://github.com/deathaxe/sublime-packages/blob/1f85741fb1ecbfd46056993248e652efc411274a/Java/HTML%20(JSP).sublime-syntax#L31-L101

Preferred solution

How about supporting variables in embed arguments?

The extending syntax would just need to define a variable with a different scope to be embedded, then. One line to catch them all. The linked lines above could be removed then.

HTML.sublime-syntax

variables:
  my_css_scope_name: 'scope:source.css.embedded.html'

contexts:
  style-css-content:
    - meta_include_prototype: false
    - match: ''
      embed: '{{my_css_scope_name}}'
      embed_scope: source.css.embedded.html
      escape: '{{style_close_lookahead}}'

HTML (JSP).sublime-syntax

variables:
  my_css_scope_name: 'scope:source.css.embedded.jsp'

Alternatives

?

Additional Information (optional)

wbond commented 3 years ago

This would end up being a request for variables being supported in all "targets". Embed, push and set all refer to other contexts in the same way, so if one supported variables, I would expect all of them to.

deathaxe commented 3 years ago

Probably yes, but I am not sure, which doors that would open.

Just looking for a method to enable an inherited syntax to easily modify embedded syntaxes without repeating too much patterns. Not sure if the whole target should allow variables or if it should be limited to scope:{{scope_name}} to force it to external contexts/syntaxes only. The ladder one wouldn't work well with embedding via path/filename such as Packages/CSS/CSS.sublime-syntax though.

sublimehq / sublime_text