tsergiu

Not sure what you mean. It's working for me. Can you describe what happens in more detail please.

Sorry about the lacking support. The goal for the next release is to have full support for Javascript flavor regexes.

But at least you can fix them quickly ;)

Not in this release. It's exact matches only for now.

Keep in mind that it doesn't support flags yet, which is why it wouldn't work out-of-the-box.

I think you are missing lower case letters in your character sets.

Besides that, apologies for it stretching sideways and making you scroll. Will be fixed in a future release!

Multiple matches is planned for a future release.

How would you recommend generating fail string? The space of failing strings is really large. From my discussions with users, they usually have a specific failed string and they want to see why it doesn't work.

The current release only supports exact matches. Multiple matches are planned for a future release.

However, if you use the slider to slide to just past the "s" in Nashville, you can see that the end state does indeed light up.

Looking into it.

That is a good visualization. However, it doesn't let you debug if there is a problem with matching a string. That was the explicit goal in building Debuggex.

Linting is a planned feature for a future release.

The text to match field is a text area; it will auto-expand as you type into it.

However, only exact matches are supported for the first release. I wanted to get user feedback before I built any more features. I think I have an intuitive way to visualize findAll() type matches.

Imagine walking from the start to the end along the railroad diagram. Every time you come to a split in the road, you choose a random one. Every time you come to a character set, you choose something random inside there. That's all there is to it.

It's done with SVG. Everyting will work on your smartphone. (Try it!)

Great to hear that :) Let me know if there's any features I can add that would make them less confusing for you.

Yes, the intention was to help solve those cases where you are staring at your screen because you don't know where the match went wrong.

I'm thinking of doing some tutorials geared towards teaching students in grade school how to use them. I think a visual representation would help significantly.

Full support for Javascript will be built out first. After that, Python and PCRE. In the longer term, I plan to support .NET, Java, Ruby, and POSIX.

That is my preferred way to communicate.

Yes. I've updated it to use webfonts.

You are bound to viewing the document in a browser. This may not be a problem in most cases, but console users cannot see them. There is also a large overhead in the amount of code that needs to be written to position and scale everything. For example, what if I wanted to add another line? Finally, because it's text, it's easy to move around. To build the site, I just copied some text out of some of the files I already had and stuck it where it needed to go. How would I have done it if it was a canvas element?

What you see in your browser is not the actual font. It was first transformed by typeface.js so that people without the font installed could still see what it looks like in their browsers. Some people have mentioned (seemingly great) alternatives to displaying uninstalled fonts, but I haven't had a chance to try them out. If you were to view text with the actual font, it would have no problems scaling.

It was the first thing I found.

It does. In your browser it may appear fuzzy because it is first passed through a filter before being displayed (see http://typeface.neocracy.org/).