Update number pattern to catch variables containing numbers

[lachieh]

Currently, numbers are matched based on the word boundary (\b) but that means that a valid variable identifier like $0 will have the 0 highlighted as a number.

Resolves #3645

Changes

• Updated the regex patterns for numbers to lookbehind for a $ symbol.

Checklist

• Added markup tests, or they don't apply here because...
• Updated the changelog at CHANGES.md

[joshgoebel]

Awesome contribution! Great tests.

Sadly, we can't use look-behinds, they aren't yet supported universal by all browsers (ie: Safari).

Typically for things like this you'd instead try to match the offending item... ie, add an earlier rule to match/capture $2323 patterns, and just ignore them (vs highlight)... this will prevent the number rule from firing and should also be another easy fix.

[taufik-nurrohman]

Yes. Adding [$][a-z\d]* as variable pattern before the number patterns should fix the issue. As the variable name that contains number has been captured before reaching the number matcher.

[joshgoebel]

[$][a-z\d]*

We don't need a-z though since all we're trying to solve is the false-positive with $[number], yes?

[taufik-nurrohman]

OK. FYI, this also happen in default JacaScript’s syntax highlighter in Vim.

[lachieh]

Awesome contribution! Great tests.

Sadly, we can't use look-behinds, they aren't yet supported universal by all browsers (ie: Safari).

I thought about this, but used it since there are two other tests patterns that also use look behinds. The suggested solution before will work though so I'll look at that.

[joshgoebel]

Two other tests? Where?

[lachieh]

Nevermind, did a cursory search and found this, but didn't notice it was a comment.

highlight.js/src/languages/r.js

Lines 173 to 176 in abcb53d

	// TODO: replace with negative look-behind when available
	// { begin: /(?<![a-zA-Z0-9._])0[xX][0-9a-fA-F]+\.[0-9a-fA-F]*[pP][+-]?\d+i?/ },
	// { begin: /(?<![a-zA-Z0-9._])0[xX][0-9a-fA-F]+([pP][+-]?\d+)?[Li]?/ },
	// { begin: /(?<![a-zA-Z0-9._])(\d+(\.\d*)?|\.\d+)([eE][+-]?\d+)?[Li]?/ }

I will update with the suggested pattern!

[lachieh]

Ok, this has been updated. I did have to leave the a-z in because it was failing on the test below. Adding the a-z in makes all tests pass.

 1) typescript
       should markup identifiers_that_include_keywords:

- actual
+ expected

-<span class="hljs-keyword">const</span> result = $<span class="hljs-title function_">class</span>();
+<span class="hljs-keyword">const</span> result = $class();

[joshgoebel]

I did have to leave the a-z in because it was failing on the test below.

Isn't that because you are using * when it should be +?

/[$]\d+/

We don't care about just plain $ unless it's followed by variable like stuff... All you're really trying to skip is $\d (false positives for numbers inside variables) so that should be a sufficient regex IF you require at least a single digit after the $, which + will do for you.

[lachieh]

Yes, fair point. Thanks for clarifying. Updated pattern and merged upstream.

[joshgoebel]

Oh, you made it a variant..... :-). Interesting. I'll fix.

[lachieh]

Yeah, took reference from here:

highlight.js/src/languages/python.js

Lines 332 to 338 in e0f7577

	variants: [
	// Exclude params in functions without params
	{
	className: "",
	begin: /\(\s*\)/,
	skip: true
	},

[joshgoebel]

Yeah, took reference from here:

Yeah, but that example sort of IS still an instance of params, just "empty params"... where as $123 isn't really an instance of a numeric, it's a variable. :-). I'm being pedantic now.

But what you're doing is one easy way to get that rule in all the same spots you'd want the NUMBER rule (which is convenient)... so that's an argument for it... so I might just revert and commit your last revision after all. :-)

[lachieh]

Gotcha, I understand. I've moved it to before the both uses of NUMBER and added a few more tests for the same pattern in template strings. I think this is fine since it is only used twice, but if you'd prefer it inside the NUMBER I can make that change (or you can).

Thanks for the time and input!

[joshgoebel]

Perfect!