Yeah debuggex's output looks slightly better, on top of having a lot more options. Regulex however is open-source with nicely written javascript: https://github.com/JexCheng/regulex
Here's a side by side comparison with the regexp I wrote to parse URLs [0]
Thanks for sharing it here. Actually I didn't intend to publish this tool at the beginning,because there are some already. This tool emerges from a piece of extempore code which is a regex parser implemented with DFA only. Then I give it a GUI,so becomes regulex.
Debuggex and regexper are powerful,I agree,that I also hesitate whether there's any reason to publish it.
But I'd like to point out some merits of regulex:
- Regulex is dedicated to ECMAScript RegExp syntax(So I didn't plan to add PCRE support now)
- regexper.com can not point out the syntax error index precisely.(Much JS interpreter can not do that)
- regexper and debuggex both tolerate OctalEscape.
- Regulex can detect invalid backref,which is treated as OctalEscape in Debuggex and regexper.
- Because of OctalEscape's complexity, Debuggex did not parse `(\1)\1\2` correctly ( https://www.debuggex.com/r/_U1r_NxTvLan7h9R ),also regexper.And /^\1(a)$/ will match "a",not "aa".So I treat it as an error.
So at least it can be used to find javascript regex syntax error. ;)
For javascript, debuggex conforms to the regular expression implementation in google chrome (which is mostly the same as all other browsers).
Specifically, a \n in your regex where group n doesn't exist is actually interpreted as the octal \00n.
If I recall correctly, \1(a) should match just "a" because all groups start out as being empty.
Parsing regular expressions is indeed complex, and we've got a massive suite of tests to make sure our engine works correctly (with respect to the chrome implementation, since that's what most people are using js regexes for).
Thank you for the great works of debuggex, I like it.
My little tool didn't intend to act like a extreme powerful and multifunctional tool which debuggex is. I know debuggex need to conform existing regex engines,so it will be more useful and can be widely applied. But what my tool intended is another side,trying to point out errors strictly.Such as /\1(a)/ or /(\1)/ doesn't make sense, so I think the ability to report errors like this will be useful.Although js interpreter's regex engine still supports octal today,but I remove it radically(see the project README).Maybe this little feature is useful for someone. ;)
These never get old for me. I don't think I've ever used one when I needed it most, because it slips my mind as I power through building a complex regex.. but damn it, not the next time round.
Kudos to Cheng for putting this nice regexp visualization tool out there. Regexp editors are indispensable for complex regexp'es. I still come back to this minimalistic regexp editor http://rubular.com when doing regexp in ruby.
Wow, there is no shortage of great tools. I really like rubular.com - even though it is for Ruby I use it for JavaScript too. Being able to generate a url and save it in my code comments is extremely valuable when I come back to the code.
I find it more useful as it can show how each position of my test string relates to parts of my regular expression