Currently, the supported modifier names are in a predefined list, so for each new modifier, the syntax highlighter should be modified to support it properly. This is often a time-consuming process (GitHub Linguist is also updated quarterly). Furthermore, the current method tends to produce problematic cases, just consider the example below:
pattern$modifier=other|a-third-party-b,aa3p_1p_
Show screenshot
Taking the above points into account, it would make sense to introduce a solution that generally supports the following syntaxes, thus solving the above problems.
pattern-without-modifiers
pattern-with-modifiers$modifier=value,another-modifier=another-value
/regex-pattern/
! $ in the pattern
/^regex-pattern$/$modifier=value
! $ in the pattern
@@||example.com/$rpc/google.*/Create$domain=example.org,stealth
! from https://github.com/AdguardTeam/VscodeAdblockSyntax/issues/71
/^(https?://)?[a-z]{10,12}\.easy\.co($|/.*$)/$document
Requirements:
Modifiers within the modifier list should be separated by unescaped commas (, that not preceded by \).
Modifier name should be an identifier name containing only letters (a-zA-Z), numbers (0-9), horizontal lines (-) and underscores (_). It may start with a number, for example 3p. Otherwise, the modifier name is invalid.
If the modifier name is followed by an equals sign (=, assign operator), the value should normally be tokenized as an unquoted string. If the assign operator is specified but the value is missing, the modifier is invalid.
If necessary, a custom tokenization may be added to the modifier value (in which case it is different from the general approach), e.g. some modifiers may have a regex value or some kind of pipe-separated list of special control characters that must be highlighted. For example, pipe (|) should be highlighted in this case, because it is a control character:
Currently, the supported modifier names are in a predefined list, so for each new modifier, the syntax highlighter should be modified to support it properly. This is often a time-consuming process (GitHub Linguist is also updated quarterly). Furthermore, the current method tends to produce problematic cases, just consider the example below:
Show screenshot
Taking the above points into account, it would make sense to introduce a solution that generally supports the following syntaxes, thus solving the above problems.
Requirements:
,that not preceded by\).a-zA-Z), numbers (0-9), horizontal lines (-) and underscores (_). It may start with a number, for example3p. Otherwise, the modifier name is invalid.=, assign operator), the value should normally be tokenized as an unquoted string. If the assign operator is specified but the value is missing, the modifier is invalid.|) should be highlighted in this case, because it is a control character: