3 oddities

[markfilipak]

HTML.
In an HTML file containing this text: "|<", Pale Moon (and Windows Edge, too) hides it and the rest of the line (up to, but not including "\n"). But if the HTML is a web page from the net, they don't do any hiding.

Javascript.
The '.replace' method can utilize regular expressions (<sourcetext>.replace(/<rebody>/g,function(){}), and those regular expressions utilize the '.lastIndex' property, and '.lastIndex' is supposed to be writable, but (unlike other regular expression methods) writing it does not work (does not move the source index). There are a couple of workarounds.

Javascript.
Regular expression terms are supposed to be greedy by default, however, /\.+/ is non-greedy by default. Workaround: /(\.+)([^\.])/ and do this: '<re>.lastIndex--', in the function -- that's supposing that '.lastIndex' works (see previous paragraph).

[therube]

Oh, I know about zero JavaScript & about one in Regex...

Seems * & + should be greedy, PCRE Regex Cheatsheet.

But BRU & Everything look to indicate that they're searching non-greedy?
(Unless my (.*) is throwing things off. And given that regex differs depending on implementation...)
.

[markfilipak]

Howdy,

/\./+/ is not /.+/ (and /\.*/ is not /.*/).

In each case, the 1st matches '.', the 2nd matches any character (and end-of-line, whether 1 char or 2 chars). The 2nd may -- probably does -- work properly.

A greedy term can be made non-greedy by adding '?', but a non-greedy term that is supposed to be greedy cannot be made greedy except by the technique I presented.

[Moonchild]

Just a note: Please don't expect browser regex to be 100% PCRE compliant -- it isn't and won't be.

[markfilipak]

Hi MC!

Just a note: Please don't expect browser regex to be 100% PCRE compliant -- it isn't and won't be.

I'm not writing production code. I'm writing a format translator: from tokenized-text to HTML, for my own use, as a bulk utility. All that I require is that regex be consistent and predictable. I just thought I would share what I've found that seems inconsistent, for your (and others') benefit.

My latest discovery is that regex seems to think that /\n/ doesn't match /[^\|]/. I'm working on a workaround.

[adesh]

About consistency:
In practive I've found that Regex is almost never consistent. There are different flavours that different languages and platforms support, be it Java, Bash, Vim, JavaScript etc. For this reason I always thoroughly test regex related functionality instead of relying on consistency.

[markfilipak]

Thanks for your reply. By "consistent" I meant consistent solely within PM, not consistent across differing implementations of regex.

[Moonchild]

I strongly recommend you have a look at regexbuddy. It's a great tool that supports tons of regex dialects, offers immediate regex analysis and testing of the resulting rules.
http://www.regexbuddy.com/

[markfilipak]

Thanks, MC. I'll look it over.

[New Tobin Paradigm]

I personally favor https://regex101.com/ my self because I simply need something quick when I have no choice but to use a regex. But Moonchild's option would be superior.