As someone who has crafted thousands of complex regular expression rules for data capture, here is my take:<p>1. This is a fine idea to aid regex newbies in crafting their expressions. I see this as a gateway instead of a longterm tool. The expressions won't be optimal (by no fault of the tool), nor will they likely be complete, but that's not the point. If it helps reduce the barrier(s) to adoption of regular expressions, then I can heartily support it.<p>2. To the people who say they use regular expressions only a handful of times a year, thus it's not worthwhile to invest time in learning the syntax, I offer this: once you know it, you will use it far more often than you ever expected. Find & replace text, piping output, Nginx.conf editing, or even the REGEXP() function in MySQL. It's a valuable skillset in so many environments that I expect you will use weekly, if not daily.<p>3. Ultimately regular expressions, like everything, are extra difficult until you know all of the available tools in the toolbox. At that point, you may realize you wrote an unnecessarily complex expression simply because you didn't know better.
Our tool[0] for using persuasion principles on your site to increase conversion had a UX problem when setting things up. We'd like to have a generic way to detect what type of page a certain url is. Most obvious way was to go with regular expressions (/.<i>\-.</i>\-d+\.html for product pages for example).<p>Turned out this was by far the most misunderstood setting while it was most of the important ones. Target audience had something to do with it (marketeers), but even when Google analytics or google tag manager is widely used by them, setting up these expressions is really hard.<p>We decided to built an internal tool that generates a regular expression based on examples for which the regex must hold. We called it the regexhelper. It was so successfull that we made it into an external tool[1].<p>It's not perfect (in terms of generating the most efficient regexes), but it works fantastic for our audiences of marketeers. Planning to open source this as well!<p>An visual UI when dealing with regexes that are the result of our helper using this idea could be beneficial.<p>[0] <a href="https://www.conversify.com" rel="nofollow">https://www.conversify.com</a><p>[1] <a href="http://regexhelper.conversify.com/" rel="nofollow">http://regexhelper.conversify.com/</a>
If you want readable regexp, just use combinators and your language's variable declaration facilities. No need for more.<p>I don't understand why people still insist on using insane syntax for regexps instead of just ... functions (`rep` for repetition, `seq` for sequences, `opt` for optional ..).
The problem with "regex" is that it left the pure computer science realm of true regular expressions, and thus lost many of the mathematical properties of regular expressions.<p>Regex's are then further abused to do things far beyond what true regular expressions can do, which results in cryptic regex expressions whose behaviors are implementation dependent instead of bounded by computer science principles.<p>Lua creator Roberto Ierusalimschy resurfaced and explored the idea of PEGs (Parsing Expression Grammars) as a better way to do the things that people have abused regex to do, while keeping it grounded in pure CS principles, allowing better syntax making things easier to express, more powerful behavior, mathematically grounded complexity (for performance), and more clarity in what can and cannot be accomplished.<p>This video presentation from the Lua Workshop explains all of this and more about why PEGs.
<a href="https://vimeo.com/1485123" rel="nofollow">https://vimeo.com/1485123</a>
I can see the claimed advantages to what's proposed, but I feel like if the railroad diagram by RegExper could be reversed, that that would be a far more successful visual syntax for regular expressions. Then again, most of my regex-fu entails building a regex relatively close to what I want and then repeatedly throwing it at a local instance of RegExper and test strings until I have something which accomplishes what I'm looking for it to do. I'd definitely fall outside the "true regex superheroes" category.<p>Anyway, to simplify what I have in mind for us less-than-experts, it'd be neat if someone could put together a railroad diagram of a regular expression that would then be compiled as the regex itself.<p>That being said, I don't have the presence of mind right now to determine if two different regexes can result in the same diagram in RegExper. If so, that kinda thoroughly breaks my idea.
I understand that the first email regex is simplified and as a result doesn't handle oddities such as weird symbols, quotations and IP addresses, but it should be able to handle modern TLDs. Not only do you have names longer than 4 characters, but internationalised domain names starting with --.<p><a href="https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains" rel="nofollow">https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...</a><p>Depending how simple you want it either:<p>\b[A-Z0–9._%+-]+@[A-Z0–9.-]+\.(xn--[A-Z0-9]|[A-Z]+)\b<p>or simpler:<p>\b[A-Z0–9._%+-]+@[A-Z0–9.-]+\.[A-Z0-9-]+\b<p>However you could argue that validating email via regex misses the point entirely. A simple, permissive regex is all you really need assuming you are actually sending an email to check that the account exists.
In the past I've used kodos, but as time has gone on I've needed it less and less:<p><a href="http://kodos.sourceforge.net/" rel="nofollow">http://kodos.sourceforge.net/</a><p>As a result I'm not into the idea of such a visualisation; you should be using regexps all the time, and internalising the rules. When that's not enough you have to go and read up. I'm not sure such a visualisation will help that much in those non-regular cases, simply because they won't always be available to hand.
Stuff like this while well intentioned is ultimately harmful, regex always looked like total gibberish to me, then one weekend I sat myself down and actually learnt it, no more issues. It's really simpler than it seems and worth the effort to learn, programs like this just work as a crutch.
When i read the "graphical" version i missed the a major issue with that email verifier, it only allows emails in UPPER CASE.<p>Spotted it directly in the normal one.<p>That says something.<p>PS, i do think it looks rather nice.
I'll be really interested to see others' reactions to this. My first impression when I glanced over the example construction was not good. I felt like it really didn't improve comprehension, but just forced me to try to learn a new way of seeing those symbols. Perhaps a visual regex "IDE" that completely abstracted the syntax would be a better approach.
Depends on what you mean by "parse". If all you want is to search a document that is known to be well-formed, find an element that meets a few criteria, and grab a value out of that element, you can sometimes get away with using regex to find a substring that "looks right" without actually parsing the document.
Running your document through an actual parser gives you access to more information about the structure of the document and the context of the elements of interest. Actually parsing your input is therefore more robust to unexpected variations than any of the superficially-cheaper alternatives that people try.
My #1 issue with regex is just knowing the damn syntax. Every implementation is a little bit different.<p>Is there a good website that lets me select a language/platform/IDE/etc and cleanly shows all the tools in that particular toolbox?
What about using this pattern matching visualisation with SNOBOL? I'd suggest it could be better for this than RegEx.<p><a href="http://langexplr.blogspot.co.uk/2007/12/quick-look-at-snobol.html?m=1" rel="nofollow">http://langexplr.blogspot.co.uk/2007/12/quick-look-at-snobol...</a><p>"The most interesting thing about the language is the string pattern matching capabilities. Here's an small(and very incomplete) example that extracts the parts of a simplified URL string:<p><pre><code> LETTER = "abcdefghijklmnopqrstuvwxyz"
LETTERORDOT = "." LETTER
LETTERORSLASH = "/" LETTER
LINE = INPUT
LINE SPAN(LETTER) . PROTO "://" SPAN(LETTERORDOT) . HOST "/" SPAN(LETTERORSLASH) . RES
OUTPUT = PROTO
OUTPUT = HOST
OUTPUT = RES</code></pre>
END<p>In line 6, the contents of the LINE variable is matched against a pattern. The pattern contains the following elements:<p>1.The SPAN(LETTER) . PROTO "://" section says identify a sequence of letters followed by "://" and assign them to the variable called PROTO<p>2.The SPAN(LETTERORDOT) . HOST "/" secotion says take a sequence of letters and dots followed by "/" and assign then to the variable called HOST<p>3.Finally the last section takes the remaining letters and slash characters and assign them to the RES variable"
Any time I want to write some non trivial regex I use <a href="https://debuggex.com/" rel="nofollow">https://debuggex.com/</a> to check/write it.
It is also great to quickly find out what a regular expression that someone else write actually does.
This helped me master regular expressions:<p><a href="http://www.amazon.com/Mastering-Regular-Expressions-Jeffrey-Friedl/dp/0596528124/" rel="nofollow">http://www.amazon.com/Mastering-Regular-Expressions-Jeffrey-...</a><p>once I read that, it was AWK forever.