Issue with Regex Tool's Lack of Support for Lazy Quantifier "{,M}" Without Lower Limit

[huxiaogang927]

The lazy quantifier, denoted by "{,M}", is a valuable feature in regex patterns. It allows for a non-greedy matching behavior by matching the shortest possible sequence of characters that fulfils the pattern's conditions. This is particularly useful in scenarios where flexibility in the length of the matched text is required, and specifying an exact lower limit is unnecessary.

However, I have observed that the regex tool provided by [Tool/Platform] does not accept the "{,M}" format and requires a lower limit to be explicitly defined using either "{N,M}" or "{0,M}". This limitation restricts the tool's versatility and hinders users from achieving optimal results in some instances.

I kindly request that your development team consider addressing this issue by extending support for the "{,M}" lazy quantifier without requiring a lower limit specification. This enhancement would undoubtedly contribute to a more user-friendly and powerful regex tool, accommodating a wider range of use cases and simplifying the regex-writing process for users.

[aYorky]

I opened #510 to address this. This repository certainly doesn't seem very active though.

[lionel-rowe]

Not supported in either of the 2 regex flavors that RegExr supports.

JS:

{ DecimalDigits }
{ DecimalDigits , }
{ DecimalDigits , DecimalDigits }

PCRE:

{,6} is not a quantifier, but a literal string of four characters

In JS regexes, {,6} either matches the literal string {,6} (in non-unicode mode regexes) or throws upon creation (in unicode mode regexes, i.e. when u or v flags are used).

The only place I've seen {,n} syntax explicitly supported is in the Xbench tool's (rather non-standard) regex implementation, where {,n} means 1..n instances, not 0..n. I'm not sure how common the syntax is, or whether the most common semantics is 0..n or 1..n.

Anyhow, both JS and PCRE flavors support explicitly specifying {0,n} or {1,n}. It seems unlikely they'll ever add support for {,n} given compatibility concerns and the ambiguous semantics.