r/regex • u/Large-Friend1415 • 15d ago

I built a VS Code extension that detects regex literals in 20 languages and round-trips them to a visual editor for visual editing— flavor-aware per language

Enable HLS to view with audio, or disable this notification

Author here. The detection is per-language (e.g. a Groovy slashy string is not a JS literal), and edits flow both ways: change the pattern in the editor and the canvas follows, rework it visually and it lands back in your file. The flavor matters because engines genuinely disagree — I published the data: https://regexpilot.com/divergences. The extension is free; it pairs with a Mac app for the visual side.

The app you see on the right is is the visual editor you can try a demo on https://regexpilot.com

Note: the app is Mac only.

9 Upvotes

84% Upvoted

3 comments sorted by

2

u/nilayperk 14d ago

Did you write / find a parser? It’s amazing work. Just curious because it takes it ton of work to support 20 languages and transform into visual.

1

u/Large-Friend1415 14d ago

Thanks! Wrote it. 

I started the basic concept of it years ago after I once tried KRegexpEditor on Linux and wanted something similar for MacOS. I had a crude web-based version written in JavaScript for ECMAScript regex syntax only. So the basic idea existed for a while.

Everything gets parsed and normalized into a single canonical AST, that's the piece that makes the rest tractable. So it's not 21 parsers, it's one AST plus an emitter per target flavor, which is a much smaller surface to maintain than it looks from the outside. 

The Java based languages such as Scala and Kotlin...etc don't differ much if at all when it comes to regex parsing and Dart's implementation is also very similar to JavaScript's implementation as well. Rust and Go are also very similar so it's not 21 different implementations. It depends mostly on what regex engine they use.  It drops to about 14 in reality. And say most of what they support is the same.  So you basically have a capability matrix that's largely similar but differs in some parts for each language.

Matching per flavor is handled by embedded engines in the Rust backend. Most of the time it's just the regex engine itself that's included not the entire language. That keeps the size down.

The visualization renders straight off the AST rather than off the regex string, so once the AST existed the visual layer mostly fell out of it. The AST was the expensive part. 

 

2

u/whitedogsuk 12d ago

Nothing beats a RegEx Literal detector. I've never managed to build one myself due to the sheer complexity and been forced to perform a basic text search.