C# Syntax Highlighting Fails for Identifiers which Violate Standard Camel Casing Rules (i.e. System.IO)

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Enter C# (and presumably Java) code which has a non-camel-cased
identifier such as System.IO or Encoding.UTF8
(Please include HTML, not just your source code)

What is the expected output?  What do you see instead?
The identifier should be highlighted (green), but instead the identifier
will not be highlighted due to the non-camel-casing. 

What version are you using?  On what browser?
I have not personally used this library, however I was referred here from
http://meta.stackoverflow.com in response to this question:
http://meta.stackoverflow.com/questions/47170/syntax-highlighting-two-character-
identifiers.
An individual there indicated it is this library which is used for code
highlighting on the Stack Overflow network of websites and suggested I
bring the question here.

Please provide any additional information below.
If the identifier follows camel casing rules then it will be properly
highlighted, but in the case of certain identifiers, namely those
consisting of only two characters (such as IO) it is the standard (in C#)
to capitalize both letters.

Original issue reported on code.google.com by laka...@gmail.com on 20 Apr 2010 at 3:43

Attachments:

• syntaxhighlighting.jpg

[GoogleCodeExporter]

http://www.bime.ntu.edu.tw/~ttlin/Course02/download_files/TECH_NOTE_02.PDF says

10).   Constant Naming Guidelines 
The names of variables declared class constants should be all uppercase with 
words 
separated by underscores. It is recommended to use a grouping naming schema. 
Example (for group AP_WIN): 
AP_WIN_MIN_WIDTH, AP_WIN_MAX_WIDTH, AP_WIN_MIN_HIGHT, AP_WIN_MAX_HIGHT

The problem I see is that names that are all upper-case with no underscores 
could be constants, or could be upper-camel-cased  namespace, class or method 
names.  "IO" in particular, could also be an interface name.

Would you suggest that I special case these names or is there some way, without 
a full-parse, to distinguish the two.

Original comment by mikesamuel@gmail.com on 5 Mar 2011 at 4:29

[GoogleCodeExporter]

Closing for lack of activity.

Original comment by mikesamuel@gmail.com on 5 Feb 2013 at 12:46

• Changed state: WillNotFix

[GoogleCodeExporter]

Given the constraints cited in your comment 2 years ago, I can see why this is 
problematic. Short of parsing the code it would be difficult to infer what 
should happen in this scenario.

Original comment by laka...@gmail.com on 5 Feb 2013 at 4:26