3 ms·

> Unfortunately, backreferences, lookahead and lookbehind cannot be supported without major changes that alter asymptotic worst-case complexity. I live and die

> Unfortunately, backreferences, lookahead and lookbehind cannot be supported without major changes that alter asymptotic worst-case complexity. I live and die by regexes, and regexes without backreferences and lookahead would be pretty useless to me. I guess such regexes are useful for _something_, but I am not sure what it would be.

rozab 6y ago
Ripgrep (and by extension, vscode) does not have these features for the same reasons. It turns out you can usually find a way of doing what you need without using these features. People got by without them for a long time.
- burntsushi 6y ago
  Note that the default regex engine does not. But ripgrep (including the version of ripgrep bundled with VS Code) does permit being built with PCRE2, which allows one to use the -P/--pcre2 flag to switch regex engines. You can even use '--engine auto' to have ripgrep automatically select the regex engine. With that said, I of course agree with your broader point. To say that regexes are "useless" without look-around/backreferences is absolutely ridiculous.
barrkel 6y ago
If you're using references a lot, you're probably using regexes for something where a parser would be a better fit. You say you live and die by regexes, but most people don't. Most people use regexes for simple validation, and text field extraction from static text patterns; e.g. extracting metrics from log lines. You don't need fancy features to pattern-match a number.
- IlliOnato 6y ago
 > You don't need fancy features to pattern-match a number. You would be surprised. If by a number you don't mean just a sequence of digits, and includes say floating point numbers, a regex to match it surprisingly complex. Most of what I do with regexes (or similar constructs) is processing text. Extracting information from human-produced text, mostly. No, a parsed won't help me. And, contrary to common belief, even processing XML (more precisely, XML fragments) sometimes makes more sense to do with regexes than with a parser. Specifically, when dealing with so-called "mixed contents", which is basically is just text with XML elements used for face markup. For example, suppose you need to find in a text an ordinal number, that can look like "5th". Of course it can be at the top level, as in "My 5th text", or within other face markup, as in "My 2nd italic text", perhaps nested, as in "My 2nd italic text". Matching it using a parser while handling all these possibilities is hellishly difficult and verbose. With regexes it's straightforward and compact. Parser is great what what you dealing is true hierarchical, or when you don't care much about what's marked up (e.g. transforms). When dealing with what's essentially is just rich text, it's much less helpful.
 - madflame991 6y ago
 Now I'm genuinely curious: I want to see the fancy features used when writing a regex for floating point numbers :)
recursive 6y ago
I regularly write trival regexes like /\d+/ to grab integers out of unstructured text.

rozab 6y ago

Ripgrep (and by extension, vscode) does not have these features for the same reasons. It turns out you can usually find a way of doing what you need without using these features. People got by without them for a long time.

burntsushi 6y ago
Note that the default regex engine does not. But ripgrep (including the version of ripgrep bundled with VS Code) does permit being built with PCRE2, which allows one to use the -P/--pcre2 flag to switch regex engines. You can even use '--engine auto' to have ripgrep automatically select the regex engine. With that said, I of course agree with your broader point. To say that regexes are "useless" without look-around/backreferences is absolutely ridiculous.

barrkel 6y ago

If you're using references a lot, you're probably using regexes for something where a parser would be a better fit. You say you live and die by regexes, but most people don't. Most people use regexes for simple validation, and text field extraction from static text patterns; e.g. extracting metrics from log lines. You don't need fancy features to pattern-match a number.

IlliOnato 6y ago
> You don't need fancy features to pattern-match a number. You would be surprised. If by a number you don't mean just a sequence of digits, and includes say floating point numbers, a regex to match it surprisingly complex. Most of what I do with regexes (or similar constructs) is processing text. Extracting information from human-produced text, mostly. No, a parsed won't help me. And, contrary to common belief, even processing XML (more precisely, XML fragments) sometimes makes more sense to do with regexes than with a parser. Specifically, when dealing with so-called "mixed contents", which is basically is just text with XML elements used for face markup. For example, suppose you need to find in a text an ordinal number, that can look like "5th". Of course it can be at the top level, as in "My 5th text", or within other face markup, as in "My 2nd italic text", perhaps nested, as in "My 2nd italic text". Matching it using a parser while handling all these possibilities is hellishly difficult and verbose. With regexes it's straightforward and compact. Parser is great what what you dealing is true hierarchical, or when you don't care much about what's marked up (e.g. transforms). When dealing with what's essentially is just rich text, it's much less helpful.
- madflame991 6y ago
 Now I'm genuinely curious: I want to see the fancy features used when writing a regex for floating point numbers :)

recursive 6y ago

I regularly write trival regexes like /\d+/ to grab integers out of unstructured text.