In our language, we wish to colorize keywords that represent global variable names, function names, enum type names, etc. To do this requires the information provided by the results of the Semantic Parse. We've come up with two solutions, neither of which is 100% correct. I was hoping I could get some help with the problem.
Solution #1:
After the Semantic Parse has identified all of the keywords that can be colorized, we go back through the Document's Token collection and fixup the Tokens so they'll get highlighted correctly.
Problems:
* This is not a thread-safe operation with the SemanticParsingService, but I found I could get it to work by "hacking" it with a try-catch.
* After altering the Tokens, the colors didn't change unless I somehow refreshed or invalidated the window. I could do this by alt-tabbing away and then back again, or highlighting the text.
The Fix:
If I could programmatically trigger a refresh, I'd be good to go. I tried calling Refresh and Invalidate on the Document but neither succeeded in what I wanted them to do. Stumped, it was at this point that I moved to Solution 2.
Solution #2:
I have a global keyword cache that is very similar to the DotNetProjectResolver, including how it saves the cache items to disk. Due to the way I'm using it, 9 times out 10 I already know all of the keywords before that first Lexical and Semantic Parse. So in the Lexical Parse when I identify keywords, I look into the cache to see how to colorize them.
Problems:
* That 9 times out of 10 bit. If it is the very first time parsing the file, I don't have its keywords in the cache, so they won't be colorized until the 2nd time the file gets lexically parsed. After the first semantic parse, the keywords get saved to disk and will be preloaded the next time the file is loaded.
* In the Lexical Parser, I get keywords colorized that shouldn't be due to file dependencies. Say I have FileA loaded which defines "int myInteger". Then I load FileB, which includes FileA. Any instances of "myInteger" get colorized, as they should. But if I load up FileC, which does not include FileA, "myInteger" gets incorrectly colorized.
The Fix:
If I knew which Document was being parsed by the lexer when GetNextTokenLexicalParseData is called (in the case of a class derived from IMergableLexicalParser), I could figure out if a keyword was in scope and colorize it correctly.
Any help you could provide concerning either solution would be greatly appreciated.
Solution #1:
After the Semantic Parse has identified all of the keywords that can be colorized, we go back through the Document's Token collection and fixup the Tokens so they'll get highlighted correctly.
Problems:
* This is not a thread-safe operation with the SemanticParsingService, but I found I could get it to work by "hacking" it with a try-catch.
* After altering the Tokens, the colors didn't change unless I somehow refreshed or invalidated the window. I could do this by alt-tabbing away and then back again, or highlighting the text.
The Fix:
If I could programmatically trigger a refresh, I'd be good to go. I tried calling Refresh and Invalidate on the Document but neither succeeded in what I wanted them to do. Stumped, it was at this point that I moved to Solution 2.
Solution #2:
I have a global keyword cache that is very similar to the DotNetProjectResolver, including how it saves the cache items to disk. Due to the way I'm using it, 9 times out 10 I already know all of the keywords before that first Lexical and Semantic Parse. So in the Lexical Parse when I identify keywords, I look into the cache to see how to colorize them.
Problems:
* That 9 times out of 10 bit. If it is the very first time parsing the file, I don't have its keywords in the cache, so they won't be colorized until the 2nd time the file gets lexically parsed. After the first semantic parse, the keywords get saved to disk and will be preloaded the next time the file is loaded.
* In the Lexical Parser, I get keywords colorized that shouldn't be due to file dependencies. Say I have FileA loaded which defines "int myInteger". Then I load FileB, which includes FileA. Any instances of "myInteger" get colorized, as they should. But if I load up FileC, which does not include FileA, "myInteger" gets incorrectly colorized.
The Fix:
If I knew which Document was being parsed by the lexer when GetNextTokenLexicalParseData is called (in the case of a class derived from IMergableLexicalParser), I could figure out if a keyword was in scope and colorize it correctly.
Any help you could provide concerning either solution would be greatly appreciated.
