How to Enable Syntax Coloring of Pattern Match Variable Only (i.e. Without Coloring any Associated Pattern)?


Syntax coloring for the following function definition

foo[x_List] := ...

will color green (and italicize by default) the argument name x as well as the pattern name _List:

enter image description here

On the other hand, syntax coloring for


colors only the identifier x green and not the _List qualifier:

enter image description here

Is there a way to configure the front end to color just the identifier name as in the second example?

Looking through the Option Inspector, I cannot find any relevant switches, so I suspect not. I do wonder however if this behavior is a bug or a feature whose purpose I don't fully understand.

EDIT: The remaining issue in this question is the following: The syntax coloring rule which specifies that function argument names should be colored green in the body of the function in which these names are bound also colors green any head to the right of the underscore that is present for pattern matching purposes. In what sense is the underscore itself and any head that is attached to it part of the function argument name proper?

The two examples provided above exhibit a pair of semantically equivalent function definitions where the coloring (which is syntax) is applied differently to semantically equivalent parts of the respective function definitions.

EDIT: Here is another example where the syntax coloring rule for pattern names is being applied in a seemingly inconsistent fashion:

f[a + b] + f[a + c] /. f[a + x_] + f[a + y_] -> p[x, y]

Shouldn't the x and the y arguments in p[x,y] be colored green much like in a function definition (whose syntax also defines a transformation rule)?

Another puzzling example:

MatchQ[{1, 1}, {x_?IntegerQ, x_ /; x > 0}]

In my front-end (v8) the first x is black. On the other hand, the second and third instances are colored green.

These examples raise the issue of whether or not color syntax rules for pattern names as they are currently implemented cause more confusion than they are worth for helping the user visualize lexical scopes that are in force at a particular position in the code. Anyone else agree?


Posted 2012-05-01T06:31:23.483

Reputation: 1 453

Regarding your recent edit, I don't find that puzzling. The first instance of x_ is naked, while x_ and x is a pairing as the highlighting indicates. I am sorry that Mathematica does not have (AFAIK) more customizable highlighting to suit your wishes. It also bothers me that highlighting is not provided for {x} ~Block~ Mod[x, 2] or i ~Table~ {i, 5} but unlike you I find the existing highlighting internally consistent enough that I am used to it. – Mr.Wizard – 2012-06-09T08:50:39.557

@Mr.Wizard: You make a reasonable case for the second example. The first one involving p[x,y] is still a bit puzzling however. I'm glad that you find the syntax coloring rule for pattern names "consistent enough" for your own use. It would be helpful if someone could state in plain English here what the rule is so that others such as myself are not so "surprised" by the resulting application of the rule in examples like those cited above. – StackExchanger – 2012-06-09T09:05:29.983

1Sorry, I missed that one. x and y in p[x,y] should not be colored green because they are not localized; if you use RuleDelayed (:>) instead you will see that they are colored, because with that they are localized. A useful distinction. – Mr.Wizard – 2012-06-09T09:07:44.840

@Mr.Wizard: If I understand your explanation correctly, you're saying that the x, y should not be colored green on the RHS of an immediate transformation rule since any occurrence of x or y on the RHS is not being "textually replaced" by what x_ or y_ matches on the LHS before the RHS is evaluated and as such the x and y on the RHS are not referencing the corresponding pattern names on the LHS but rather symbols that may (or may not) already exist in the surround context. – StackExchanger – 2012-06-11T05:54:01.780

1Yes, that's correct. However, note that they will be replaced by the matching LHS object if they do not evaluate to something else. I always try to use :> when using named patterns on the RHS to avoid this ambiguity, though conceivably there are certain uses when this ambiguity is useful. – Mr.Wizard – 2012-06-11T06:01:44.240

@Mr.Wizard: The second example demonstrates I suppose that not just any pattern name is highlighted by the syntax coloring rule but rather only "bound" ones. – StackExchanger – 2012-06-11T06:02:33.490

1That is generally my understanding, but the highlighting is not perfect (reference ~infix~ comment above). – Mr.Wizard – 2012-06-11T06:06:04.483



I don't think it's possible, but I hope for an answer proving me wrong.

I don't think you can do anything about how the front-end interprets what you type as boxes. If you could do that, you could make something like x_Integer parse into a certain StyleBox. However, it's interpreted as a single word. Try it, and in the cell expression you'll see BoxData["x_Integer"]. I doubt the front-end allows you any way of treating parts of a word differently than others.

The front-end has some options regarding the syntax coloring, but, as you said, I found none that could apply to this. There are also some styles in the core.nb stylesheet that can be customized, such as the color of unmached brackets, but none related and particularly, none referring to "parts of words".

Similarly, the option AutoStyleWords only helps with specific full words (in box type cells). As John Fultz said in this answer

"This will only work to style things which are lexically word-type tokens. You cannot, for example, auto-style two words in sequence, a subexpression with an operator, or a substring of a word token."


I'm not totally certain, but my best guess is that your only chance is by brute force. This means, some trigger, that runs code that reads your cell's box expressions and turns them into what you like. The trigger could be a CellEventHandler that catches keystrokes, or a ScheduledTask, or some manual input, palette, hotkey, context menu, etc.

Leonid is using this approach in his syntax highlighter package, and if this is important to you, my bet is that the road through this link is your tough but best chance


Posted 2012-05-01T06:31:23.483

Reputation: 40 993

FullForm[x_Integer] is Pattern[x,Blank[Integer]] but as you point out "x_Integer" is parsed as a single word BoxData["x_Integer"]. OTOH, "x:_Integer" parses as BoxData[RowBox[{"x", ":", "_Integer"}], which can have its various subexpressions transformed according to different rules by the built-in syntax coloring engine. The (presumed) inability here of the user to customize how Mma parses an expression like "x_Integer" raises an interesting question: how exactly does Mma compare to LISP's flexibility in the area of "read-time macros"? – StackExchanger – 2012-05-20T06:37:43.533

I'll keep this question open a little longer before awarding the bounty to see what others have to offer on this issue. Thanks for your insights regarding what are probable limitations on the user's ability to modify the syntax coloring rules. This particular syntax coloring issue is not all that crucial, but I am concerned about the larger issue of what ability does the user have to customize formatting rules in the frontend which is why I'll be following the development of Leonid's package with interest. – StackExchanger – 2012-05-20T06:39:31.597

2Correct, there is no conventional way to change whether the FE chooses to color the head of a pattern in the way the StackExchanger is hoping. Somebody might come up with some creative unconventional means, but I would personally be a bit gun-shy about using such a method. – John Fultz – 2012-06-10T09:42:45.293

@JohnFultz: Thanks for chiming in here. I can easily live with the current syntax coloring rules -- studying their behavior carefully however has helped me better understand the finer points of scoping and pattern matching. I hope that a future version of Mma will allow the user to customize syntax coloring by evaluating expressions in the front-end and in the process help obviate the need for employing the kind of clever "gymnastics" contained in the package Shifrin is currently developing for this purpose. – StackExchanger – 2012-06-12T08:00:35.017


I find the difference to be helpful and provides "good to know" syntax information. In the case of using it in a "function" as you did*, naming a pattern (i.e. the : term) allows you to create much more complicated pattern matches for that element. So, while for your example, the full form of each statement evaluates the same:

In[17]:= FullForm[foo[x_List]]

Out[17]//FullForm= foo[Pattern[x,Blank[List]]]
Out[18]//FullForm= foo[Pattern[x,Blank[List]]]

For two more complicated examples (which are legal), the different notations don't make sense:

In[21]:= FullForm[foo[x{_String,_List}]]

Out[21]//FullForm= foo[List[Times[x,Blank[String]],Times[x,Blank[List]]]]
Out[22]//FullForm= foo[Pattern[x,List[Blank[String],Blank[List]]]]

Note that the first one doesn't produce a valid function, while the second one does:

In[32]:= Clear[foo]

Out[34]= {Hi,{}}

In[29]:= Clear[foo]

Out[31]= foo[{Hi,{}}]

I personally prefer the way that MMA currently does it: there should not be any highlighting on {_String,_List} in my example function foo.

* Technically you are defining a pattern matching rule, see: Functions vs. patterns


Posted 2012-05-01T06:31:23.483

Reputation: 4 819

I'm not sure that I understand your answer. Are you claiming that you prefer syntax coloring in the slightly inconsistent way that Mathematica currently performs it, or that you too prefer that only the identifier's name (and not any associated pattern matching syntax) be highlighted? – StackExchanger – 2012-05-01T17:43:37.750

@StackExchanger I believe that the way MMA currently does it is the preferred way. Tried to edit the last paragraph to make that clearer – tkott – 2012-05-01T18:15:28.623

The first one does define a valid function; it's just hard to call (because Times has attribute Listable). Here's an example how to call it: foo[Unevaluated[{x"Hello world", x{}}]]. Note the Unevaluated (to prevent x to be passed to the member of the inner list — which here would make it disappear completely because that list is empty) and the manual distribution of x for the outer list (because Unevaluated would prevent that as well, which would also cause the definition not to match). Note that the definition of foo is (as can be seen by ?foo) foo[{x*_String, x*_List}] := x – celtschk – 2012-05-01T18:52:16.263

@tkott: To be clear all I am asking here is whether or not the different way Mma >>colors<< syntax in you first code block is desirable. When the pattern is attached to the identifier name via an underscore, the pattern is colored along with the identifier name, whereas in the case that the identifier name and the pattern are separated by a colon, only the identifier (and not the pattern) is highlighted. I would prefer that both cases are handled by the same rule: only color the identifier name and not any patterns used to constrain what the name can match. – StackExchanger – 2012-05-01T18:59:49.360

Tangential to the original Q: is it possible to print notebooks w/ color highlighting? – alancalvitti – 2012-05-01T19:25:12.273

@StackExchanger Then i still answer your question: I find it desirable to have MMA color the functions the way it currently does: the two separators (: vs. _) you describe have completely different meanings in MMA, and the way MMA highlights it makes sense to me. I simply used an example to show my point why. I don't know how to change this behavior even if I didn't like it. @celtschk That's true, but I think we can agree that's a fairly convoluted function to define. – tkott – 2012-05-01T19:40:51.180

@alancalvitti See this question

– rm -rf – 2012-05-01T19:46:35.320

@tcott: Note however that even with StackExchanger's proposed change, your example would still be colored different because in your non-':' form, x does not name a pattern, but is a literal (sub-)pattern. In other words, x in the convoluted function would not be green either way. – celtschk – 2012-05-01T19:50:47.577

@R.M Well, the question does have a part about whether it makes sense: "I do wonder however if this behavior is a bug or a feature whose purpose I don't fully understand." and from his comment: "To be clear all I am asking here is whether or not the different way Mma >>colors<< syntax in you first code block is desirable."... – tkott – 2012-05-01T20:03:41.620

@tkott I understand that the two separators (: and _) correspond to different constructs (Pattern and Blank) respectively. The issue is that when _ is combined with a variable name on the left, it serves as syntax for : as your use of FullForm on the respective expressions proves. I'm asking why the syntax coloring rules don't reflect this underlying equivalence ... see second edit to original question post. – StackExchanger – 2012-05-01T21:30:08.890