Limited syntax highlighting version override based on shebang

[eugenesvk]

Problem description

There are different syntax versions for the same file extension, with the syntax version signaled in the first line, so I can differentiate between v1 and v2 by using the first_line_match
However, I can't do anything with this information since for defined extensions this first_line_match variable is ignored and a random syntax definition wins (the one that's loaded later) even if the shebang doesn't match, so it ends up with incorrect syntax highlights

Preferred solution

(the solution should work only within the same file extension to prevent the overhead of parsing shebangs for all the files)
If there are multiple syntax definitions for the same file extension, there should be an option to prioritize the one that matches the shebang

Alternatives

I thought of deleting the file extension variable in the syntax definition , but then v1 doesn't require any shebangs, so will match all the files if I add a .* or something, which is obviously undesirable

You could also change extensions, but that's rather cumbersome (especially for minor version syntax changes)

Otherwise I don' t know how to fix it currently

Additional Information

No response

[michaelblyons]

Have you considered ApplySyntax or AutoSetSyntax from Package Control?

[eugenesvk]

ApplySyntax

Thanks for the suggestions!
I'm using this one, though it doesn't seem to be able to override the default syntax (either v1 or v2: if I have v2 installed that extends v1, then v2 is always applied, if I delete file_extensions from v2 so that it doesn't override v1, then ApplySyntax stil fails to override v1 even for files with a first_line match (though the same rule works for unsyntaxed files with a first_line if I change extension to .syntaxv2 or something))
I've instead just written my own little plugin that overrides the override :) of v2 for files that don't have a shebang and converts them back to v1, and that only works within a given extension, but in general, this seems like a waste parsing shebangs multiple times natively and in a plugin.
Also it'd be great not to require users adding this extra complication if a syntax plugin wants to include several syntaxes for the same file extension

AutoSetSyntax

This seems like a more advanced one and is able to override the default v2 syntax override via a negative lookahead and return a file back to v1, though as I mentioned above I believe there should be this one extra native step that allows to set better priorities in the syntax files without the plugin (since they already have a first line parsing rule)

[keith-hall]

How about having one syntax definition which has the file extension specified, and in the main context, use a lookahead to see if the first line matches your "v2" shebang, and if so, set that on the stack, otherwise set the "v1" syntax. "v2" will work with first_line_match if file extension doesn't match, and this is all possible without any changes in ST. The only drawback I can see atm is files matched by extension would show a "generic" syntax name in the status bar etc. and there's one more syntax definition in the list. (maybe make it hidden?)

[eugenesvk]

lookahead to see if the first line matches

Interesting idea, though I don't get how to limit my search to the first line since

Regexes are only ever run against a single line of text at a time.

I wouldn't want to change syntaxes if I encounter a v1 file with a shebang somewhere in a string literal in the middle of a file or something (though that should admittedly be rare)

Also, this would require duplicating the syntaxes, while currently I'm using a nice extends API that allows me to tweak only the contexts that changed with the added benefit of not requiring messing with the package's files and remembering to revert whenever the upstream updates
(though with the proper upstream changes in the syntax file this duplication would just be a duplication of a few lines of component names, so not an issue)

and there's one more syntax definition in the list. (maybe make it hidden?)

That's what #1096 is supposed to achieve :)

[keith-hall]

Probably it would be nice to (optionally, for backwards compatibility) have a way for first_line_match to still be checked even if the file extension has already matched. And in general, to have more of AutoSetSyntax's functionality available in core so that (future) features like #6530 could be more effective.