sublime-syntax single quote escapes followed by quantifier chars inside sets

[keith-hall]

In a sublime-syntax file, if the regex is single quoted, and contains a set, and that set contains an escaped single quote, if a character that is normally a valid quantifier immediately follows it, that character is scoped as a quantifier when it shouldn't be - because it is inside a set.

Example: add a star after the ' here: https://github.com/sublimehq/Packages/blob/7ef80d531b752baee46f792b6bc6b26206e56012/Rust/Rust.sublime-syntax#L383

to get:

- match: '(?=>|[^ \t\n\$=<_+''*(),&:\[\][:alnum:]])'

and you will see the * is scoped as keyword.operator.quantifier.regexp when it shouldn't be.

[FichteFoll]

I can also imagine problematic situations with match: '[x-'']+'.

[FichteFoll]

This issue is quite annoying. Without having to rewrite the entire syntax for a "single-quotes escape mode", I basically get to decide between not matching situations like `match: '\s*''?', where a quantifier would be valid but not recognized, or the current situation where a quantifier is seen within a set when it shouldn't. Since the latter is less obtrusive than the former, I'd prefer to keep it the way it is, if we had to choose between either.

Cases where the escape occurs in a set range not considered.

I don't think this issue occurs frequent enough to warrant rebuilding the entire Oniguruma syntax with single quotes in mind, so I'll pull this from the 3.0.0 milestone for later consideration. It's not a huge deal either way.

[Thom1729]

I took a stab at rebuilding the entire Oniguruma syntax with single quotes in mind:

%YAML 1.2
%TAG ! tag:yaml-macros:YAMLMacros.lib.extend:
---
!extend
_base: Oniguruma RegExp.sublime-syntax
name: Oniguruma Regular Expression (single-quoted)
hidden: true

variables: !merge
  char_escape: \\.|''

Is this a solution worth pursuing?

[FichteFoll]

Thanks for the heads up.

I kind of dislike having to require third-party tools for building resource files for ST, since it introduces yet another dependency, and was very glad when the need for YAML-tmLanguage conversions was nullified by sublime-syntax being YAML already. However, I do see merit in the brevity of the YAML Macros approach and I wouldn't be able to get around having to rebuild the syntax anyway in order to fix this issue.

I'll think about this more and experiment with YAML Macros a bit. You won't have to submit this as a pull request.

[FichteFoll]

Going to wait on the YAML Macros update that includes changes from the outfactored dependency.

[FichteFoll]

Just as a heads-up, with the ability to extend syntaxes, fixing this has become a lot easier. Just waiting for someone with enough motivation to get picked up. 😉