front end - 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:

On the other hand, syntax coloring for

foo[x:_List]

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

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?

Answer

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."

Conclusion

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