(R) Numbers a not highlighted in multiple circumstances

[klmr]

Describe the issue

1. Numbers aren’t highlighted at the very start of the document
2. Numbers aren’t highlighted after  <-  (and possibly after other constructs)
3. -> is declared as illegal (to distinguish it from Haskell) despite being legal in R; this might be an OK heuristic, but the documentation makes it sound as if illegal is more than just a gentle nudge in the weighting, and this wouldn’t be appropriate.

Which language seems to have the issue?

R

Are you using highlight or highlightAuto?

highlight

Sample Code to Reproduce

1
a <- 1

Expected behavior

<span class="hljs-number">1</span>
a &lt;- <span class="hljs-number">1</span>

I’ve got a PR to fix these issues and also implements operators and punctuation highlighting at the same time. But, alas, it now fails to highlight numbers directly after operators/punctuation, because the rule for numbers eats the preceding character. I thought we had a solution for this that didn’t require look-behind, but that solution was removed in 0e9fb35 (ostensibly this shouldn’t have caused a behavioural change, so it’s possible that the previous version already had the errors described above).

Here’s the patch I used to add operators (which fixes problem (2)) and allow numbers at the beginning of the document, but this now causes numbers directly after operators to fail highlighting.

diff --git a/src/languages/r.js b/src/languages/r.js
index a4348678..5cb90f3e 100644
--- a/src/languages/r.js
+++ b/src/languages/r.js
@@ -144,32 +140,42 @@ export default function(hljs) {
           {
             // Special case: only hexadecimal binary powers can contain fractions.
             match: [
-              /[^a-zA-Z0-9._]/, // not part of an identifier
+              /[^a-zA-Z0-9._]|^/, // not part of an identifier
               /0[xX][0-9a-fA-F]+\.[0-9a-fA-F]*[pP][+-]?\d+i?/
             ]
           },
           {
             match: [
-              /[^a-zA-Z0-9._]/, // not part of an identifier
+              /[^a-zA-Z0-9._]|^/, // not part of an identifier
               /0[xX][0-9a-fA-F]+(?:[pP][+-]?\d+)?[Li]?/
             ]
           },
           {
             match: [
-              /[^a-zA-Z0-9._]/, // not part of an identifier
+              /[^a-zA-Z0-9._]|^/, // not part of an identifier
               /(?:\d+(?:\.\d*)?|\.\d+)(?:[eE][+-]?\d+)?[Li]?/
             ]
           }
         ]
       },
       {
-        // infix operator
-        begin: '%',
-        end: '%'
+        className: 'operator',
+        variants: [
+          {
+            // custom infix operator
+            begin: '%',
+            end: '%'
+          },
+          {
+            // Base operators minus replacement functions and punctuation,
+            // plus aliases.
+            match: /[=!<>:]=|\|\||&&|:::?|<-|<<-|[-+*\/?!$&|:<=>@^~]|->|->>|\*\*/
+          }
+        ]
       },
-      // relevance boost for assignment
       {
-        begin: regex.concat(SIMPLE_IDENT, "\\s+<-\\s+")
+        className: 'punctuation',
+        match: /\[\[|[(){}[\]]/
       },
       {
         // escaped identifier

[joshgoebel]

I thought we had a solution for this that didn’t require look-behind, but that solution was removed in 0e9fb35

beforeMatch was look-ahead also, it also would have consumed the prior character and you'd have the exactly same problem. We have no true look-behind solution (outside of callbacks which we prefer not to use).

You might try two variants of number using multi-match (I'm not sure how ugly it will be):

variants:
[
 { match: [
    operator_re
    regex.either(number_types)
   ],
  scope: { 1: "operator", 2: "number" }
 },
 { match: [
    not_identifier
    regex.either(number_types)
   ]},

]

IE, combining the operator into the number matcher.

[joshgoebel]

-> is declared as illegal (to distinguish it from Haskell) despite being legal in R;

That would probably be incorrect then, though sometimes context matters... like perhaps it's invalid in a certain scope, but valid in others...

[klmr]

OK, I think I’ve got it. PR coming in 3…2…1…

[joshgoebel]

Talk about anti-climatic. :)