2 ms·
It doesn't seem to be able to handle character classes of the type [^abc], which matches any character except a, b, or c. It's pretty cool, though. I tried copy
by pjscott 16y ago
It doesn't seem to be able to handle character classes of the type [^abc], which matches any character except a, b, or c. It's pretty cool, though. I tried copying and pasting some crazy regexps from the internet in there, and it immediately gave me some idea what they do. Well done!
- rndmcnlly0 16y agoI purposely punted on inverted character classes because they brought up a major usability issue that I didn't have a quick solution for. The expression /[^abc]/ should match '@', ' ', and 'q', but, by the numbers, the majority of generated matches would look like '{angry unicode that you can't even see}'. This brings up the idea that you don't just want valid matches, but a meaningful set of examples that covers different ways of matching. Likewise, I imagine it might be useful to specify some background language that matches should be taken from. That is, you might want to tell it to show you example matches made from snippets of valid html, from email-style English text, ascii-only strings, arbitrary unicode, etc. Incorporating this kind requires a lot of original thinking about usability (and some prototyping to figure out what would even make sense).
- nerfhammer 16y agoyou support . which seems to pick random ascii characters
- abecedarius 16y agoSince the intersection of two regular languages is a regular language, you could reduce generating 'background language' example matches to taking intersections. It's unfortunate how rare it is for libraries to provide you that operation. (Same thing for HTML: intersecting a regular language with a context-free one is context-free.)