I 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]

I 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).