Bug introduced in 9.0.1 or earlier and persists in 13.3

I'm setting up the SyntaxInformation for a package I'm writing and I'm struggling to understand what the "ColorEqualSigns" property is supposed to do, how one is meant to use it, and whether it works at all.

From what I can tell, it is meant to colour equal signs (i.e. =) red, in positions where it is likely that the intended operator is Equal, i.e. ==, instead of Set. This includes positions that normally take equations (like in Solve) or logical tests (like in Which). Is this a correct understanding of the expected behaviour?

However, I'm having trouble getting the Front End to reproduce this behaviour, both for my own functions and for the in-built ones.

For my own functions, code like

SyntaxInformation[f] = {"ColorEqualSigns" -> {1, 2}};
f[a = 1, b = 2, c = 3]

only marks the first one as an error:

enter image description here

To do the system-defined functions, one can get a comprehensive list by running

list = Select[
   {symbol, SyntaxInformation[ToExpression[symbol]]}
   , {symbol, Names["System`*"]}]
  , (("ColorEqualSigns" /. #[[2]]) =!= "ColorEqualSigns") &]

the output of which is nicely formatted by TableForm[{#1, {"ColorEqualSigns"} /. #2} & @@@ list].

And             All
DSolve          1   1
For             2   2
If              1   1
Implies         All
Nand            All
NDSolve         1   1
NDSolveValue    1   1
Nor             All
Not             All
NRoots          1   1
NSolve          1   1
Or              All
Reduce          1   1
Solve           1   1
SolveAlways     1   1
Which           Odd
While           1   1
Xor             All

From these, only If and While seem to work as intended. As a test, see the syntax colouring on the following:

And[a = 1, b = 2]
DSolve[y'[x] = y[x], y, x]
For[i = 0, i = 5, i++, Print[i]]
If[i = j, a, b]
Implies[a = b, c = d]
Nand[a = 1, b = 2]
NDSolve[y'[x] = y[x], y, x]
DSolveValue[{y'[x] = y[x] Cos[x + y[x]], y[0] = 1}, y, {x, 0, 30}]
Nor[a = 1, b = 2]
Not[a = 1]
NRoots[1 + 2 x + 3 x^2 + 4 x^3 = 0, x]
NSolve[x^5 - 2 x + 3 = 0, x]
Or[a = 1, b = 2]
Reduce[x^2 - y^3 = 1, {x, y}]
Solve[x^2 + a x + 1 = 0, x]
Solve[x^2 + a x + 1 = 0, x]
Which[a = 1, b = 2, c = 3, d = 4, e = 5, f = 6]
While[n = 4, n++]
Xor[a = 1, b = 2]

which render on my machine (MM 11.0.0, 10.3.0, 10.1.0 and 9.0.1 over Ubuntu) as

enter image description here

Note that e.g. the second equals sign in And[a = 1, b = 2] is not marked as erroneous, which is inconsistent with the rule "ColorEqualSigns" -> All in SyntaxInformation[All]. This is present at least since early 2013, as pointed out in this post.

Is this the intended behaviour?

  • 1
    $\begingroup$ I am not a Wolfram insider so I cannot answer this question but it certainly doesn't appear to be working as intended. $\endgroup$
    – Mr.Wizard
    Commented Oct 28, 2014 at 9:46
  • $\begingroup$ Appears the same way on Windows. Probably a bug. $\endgroup$
    – masterxilo
    Commented Jun 17, 2016 at 20:12

1 Answer 1


So I delved into this as part of a new effort to review things like SyntaxInformation, function templates, and so forth. Too early to say what will come of this, but feel free to send requests.

As for the specific issue of "ColorEqualSigns". First, how it's supposed to work. The allowed values (currently) are

Odd  (* see below *)
Even (* see below *)

All of these (are supposed to) have the more or less obvious meanings. But I've identified mutliple issues I have reported internally.

  1. The FE is expecting the values System`Odd and System`Even, but of course there are no such symbols. Probably just an oversight when first created--these should have been OddQ and EvenQ. Nobody noticed since only one function uses these values, namely Which. I would recommend just unprotecting Which and putting System`Odd as a workaround, except for:
  2. For some reason, the coloring is only active in the first argument. So if your spec includes the first position, you'll see it there, but not elsewhere. If the spec doesn't include 1, you won't see it anywhere. This is obviously a bug. It's a bit embarassing it wasn't noticed internally earlier.
  3. The coloring requires that the LHS be a single token. Compare the appearance of Solve[x^2 + a x + 1 = 0, x] and Solve[0 = x^2 + a x + 1, x]. This is arguably not a bug if you think of this feature descending from things like If[test,...]. If[x=0,...] is valid syntax which will quietly do the wrong thing in all cases. If[x^2+2x+1=0,...] will give you a message. Still, I feel this is not keeping with the spirit of this option and I have reported this as a bug.
  4. It doesn't enter lists and check equal signs inside. It's certainly a limitation, but it's not obviously wrong. And certainly, how many levels down does it check? Is it worth the development cost and/or performance cost? I'm not saying it wouldn't be nice to do this (I would like it), but this definitely more in the "feature request" than "bug fix" category.

So now it is reported and might actually be fixed. I can't say when, will the first is obviously easy, I don't know enough about the code to even guess at the difficulty of the others. I'll try to keep this updated as I get news.

  • 1
    $\begingroup$ It's good to see this one getting done attention =). $\endgroup$ Commented Oct 10, 2017 at 22:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.