leaverou / regexplained Goto Github PK

http://leaverou.github.com/regexplained/

Enter \\[bfnrtv0] in the first field, and \b\f\n\r\t\v\0 in the second. (On that note, permalinks would be nice ☺.) Then start hitting ↓. Notice it skips the \n and the \0. (Tested in latest Opera Next and Chrome Canary.)

The current font and use of uppercase make me think the keyboard shortcuts shown are Ctrl+| and Ctrl+Shift+m.

When _.supportsCh is false, the size of the input box is a couple of pixels too narrow to display the cursor when it's at the end of the input. This works fine if you navigate to the end using the keyboard, but if you just click there, you get no feedback.

Hi Lea,

I am a Brazilian guy that wants to translate your presentation to Portuguese.
I am here to ask your permission and if you have the slides to share with me.

Steps to reproduce: Enter a(a)(a) as the regex, and aaa as the target text. If you click "next subpattern", the first a in the text is incorrectly highlighted (it should be the second a). Click "next subpattern" again, and the first a remains highlighted (it should be the third a).

In this case, the problem stems from the fact that the backreference text can be found at multiple positions within the match. But it's possible to trigger the problem even without that, e.g., if a backreference should appear outside or partially outside of the match (thanks to lookahead), but the backreference text is also found within the match.

I know you're aware of this issue (since we previously talked about it), but IMO this is a very significant error for a tool that people will use to help them learn how regexes work.

As you know, JavaScript does not provide any way to accurately determine the starting position of subpattern matches for an arbitrary regex. But here are a couple potential ways to address this:

1. Kill the 'next/previous subpattern' feature. The feature might not be worth saving, if it's inaccurate. Instead, perhaps you could list out the subpattern matches underneath or on the side of the target text.
2. Use XHR and a programming language on the backend that allows you to determine subpattern match indexes. But then you’d run up against regex syntax and behavior differences between JavaScript and the backend regex flavor.

Example regex: (?=aa(b))a
Example subject text: aab

Currently, after advancing to the next subpattern, the second a is incorrectly highlighted. Instead, the b should be highlighted.

The current URL listed http://leaverou.github.com/regexplained/ is a 404.

The README should either be deleted (since it currently has no other content), or the URL updated to https://projects.verou.me/regexplained/ or https://regexplained.com/.

Currently, only flags i and m have buttons in the UI, and flags i, m, y, u, s are supported via keyboard (Ctrl+<X>). This leaves out some flags that would be useful:

• ES2015: flag y (sticky)
• ES2015: flag u (unicode) - A button would be extra helpful since Ctrl+U triggers View Source.
• ES2018: flag s (dotAll) - A button would be extra helpful since Ctrl+S triggers Save As.
• ES2024: flag v (unicodeSets) - Can't be used together with u. A button would be helpful since Ctrl+V triggers Paste when an input is focused.

Aside: Flags d (ES2022) and g do not need to be toggleable, based on regexplained's current feature set. But it might be nice to allow turning flag g off via Ctrl+G on the keyboard even if there isn't a button for it in the UI.

The reason is match/subpattern highlighting expects every character to take the same width due to the use of a monospace font. However, the width of e.g. English characters doesn't apply to e.g. Japanese characters.

Example: try using /./ to match "片仮名" or "カタカナ".

There's probably some way to determine the actual width of matched text as rendered on the screen, which would be a part of fixing this.

Would be cool if pattern from cheatsheet inserted into regexp field on click. May be even wrapping/overwriting selected text in some cases

The ^ character for control is not clear in the keyboard shortcuts, it required some hunting for me to figure out what the correct shortcuts were. Really cool project by the way.

What would you say about the possibility of sharing regexp/string with simple link? I'm talking about something like that: https://regexplained.com/#re=a(b),str=aabb

Personally, I like the current magical handling of treating \n and \r in the subject text as literal LF and CR characters when searching for matches. However, it's non-obvious and only works for these two tokens (and not others supported by JS string literals like \\, \t, \v, \f, \b, \xFF, etc.). Therefore, most people are likely to initially expect that the regex \\n should match \n in the subject text (it doesn't).

(Aside: because of the current handling, there is no way to make a regex of \\n match anything. It won't match \n or \\n because \\ is not given the same magic handling in the subject text and therefore, for subject text \\n, the string is considered to be \ followed by a literal LF.)

Proposal: Apply special styling to \n and \r wherever they appear in the subject text, or alternatively, automatically convert them to the characters ␊ (U+240A) and ␍ (U+240D) as soon as they're typed in the subject text, then apply the magical match handling to ␊ and ␍.

Regexplained has special handling to treat "\r" and "\n" in the subject text as literal line feed and carriage return characters, but this handling is not working correctly.

Simple case (\n at start of the match):
Regex: \n
Subject text: \n
Result: The highlighted match is n, rather than \n.

With \n in middle of the match:
Regex: a\n
Subject text: a\n
Result: The highlighted match is a\ (incorrect), rather than a\n.

With backreference highlighting:
Regex: a(\n)
Subject text: a\n
Result: When highlighting the subpattern match, the overall match is shown as a\ (incorrect) and the subpattern match is shown as n (also incorrect, and shown outside of the overall match).

Other curious variations of this issue are possible, depending e.g. on whether \n or \r appear prior to a match, within a match but prior to a subpattern match, or within a subpattern match.

Example regex 1: a(b)(c)?
Example subject text 1: ab

Example regex 2: a(b)??
Example subject text 2: ab

Example regex 3: a|(b)
Example subject text 3: a

Current behavior: After using CTRL+down to advance subpattern matching to any capturing group that did not participate in the match, a JS error is thrown and the subpattern highlighting is incorrect.

Note that non-participating capturing groups are different than non-capturing groups and also different from groups that participate in the match but capture an empty string. That's why my examples used e.g. (c)? instead of (c?) (the latter will always participate in a successful match since the group itself is not optional).

Entering whitespace at the start or end of the regex or target text boxes does not cause the visible area to expand, and causes misalignment of the match highlighting.

I'm using Chrome 19. Let me know if more details are needed.

Hello, thank you for these amazing resources! But it seems that the slides.html webpage broken.

Both these two urls:

https://regexplained.com/slides.html
https://leaverou.github.io/regexplained/slides.html