Fix compatibility with new ST4 versions

[rchl]

A non-backward compatible change was introduced in updated HTML syntax
that breaks loading of Vue syntax.

This removes context that references removed variable script_close_lookahead.
There is supposedly no point to overriding it in the first places since
there is no custom syntax introduced here.

Fixes #213

@skyronic @Thom1729 @deathaxe

[deathaxe]

All those contexts should follow the scheme of https://github.com/sublimehq/Packages/blob/c70117be6402c54ccf860ab8edfcba8aade46c9e/ASP/HTML%20(ASP).sublime-syntax#L45-L67 in order to not regress comment toggling in all those embedded syntaxes.

[rchl]

Is that approach that you are suggesting here compatible with pre-4114 builds?

[deathaxe]

Good point.

It should be enough to copy the variable declarations from current HTML.sublime-syntax to make them available in older builds and apply the scheme of those marked lines to JS and CSS.

Those marked contexts are the only ones which are involved in "fixing the toggle comment bug".

In case one of your embedded syntaxes supports --> as operator, you might need a custom strategy or just omit support for wrapping the script into html comments.

[deathaxe]

Fingers crossed. I hope we don't need to touch it again.

[deathaxe]

Otherwise looking for --> comment end here is somewhat useless.

We may omit support for wrapping syntaxes other than CSS/JS into html contexts as it is a quite old technique required for outdated browsers.

In that case the initial empty match pattern would be ok.

[deathaxe]

Suggested change

	escape: (?i)(?=(?:-->\s*)?</style{{tag_name_break_char}})
	escape: (?=</(?i:style){{tag_name_break_char}})

[rchl]

I can think of two ways we can proceed with this issue:
a) I ask you various, potentially silly, questions so that things are fully clear for me
b) I let someone else handle this whole issue since I don't fully understand your explanations and I don't feel confident making those changes.

I'll ask the questions anyway but if you or someone else wants to take over, feel free to ignore my questions.

Otherwise looking for --> comment end here is somewhat useless.

What is "otherwise" referring to? Seems like part of the sentence is missing or it's implicitly referring to something but I can't figure out what.

We may omit support for wrapping syntaxes other than CSS/JS into html contexts as it is a quite old technique required for outdated browsers.

I'm not sure I fully understand but I'd say that for the sake of compatibility the syntax has to support embedding <style> or <script> within the HTML block (<template> tag in case of the Vue file). I've seen some needs for that in the wild where one needs to generate a style block dynamically based on the JS data.

As far as supporting <style> blocks that declare to be using a preprocessor (<style lang="scss"> and such), I'm pretty sure that that is not supported by the code that handles the Vue files, even if the syntax currently supports those. That would likely result in the content not being processed by the pre-processor and thus result in non-valid CSS.

[deathaxe]

I can look into applying proper changes. Should be easy.

Not sure I can continue working on this PR directly though.

---

With "Otherwise" I refered to the suggested change in the first comment. Maybe bad english. I just had those two options in mind:

a) support wrapping embedded script code into html comments like

<script>
<!--
the code
-->
</script>

b) omit that support completely, which would require the proposed change. Not doing so would leave a trailing --> unscoped/unhighlighted.

[rchl]

Not sure I can continue working on this PR directly though.

It's OK to start a new PR.

a) support wrapping embedded script code into html comments like

This is in fact not supported within <script> tags within a Vue files so it's fine to not support it. It would cause an error when preprocessing the tag.

In fact the tags in Vue files don't directly map to plain HTML. Those are merely a way to structure the HTML, SCRIPT and STYLE within the same file. Those are processed by a library that transforms it into JS bundles so normal rules of HTML don't necessarily apply here.