Token Coloring

Hi Jake,

Actually if you write a custom lexical parser you can do that sort of thing right now. You could make styles for variables, locals, etc. and while doing the lexical parsing, return a token ID that identifies each one. Would that work for you?

That sounds fine to me, how does a custom parser fit in with your .net resolover and parser?

There currently isn't a way to plug into the parsing phase from external code. However we're open to any suggestions if you feel like brainstorming it here.

Hi,
I don't know if this would be performant or fit nicely into your program but what about a public dictionary that strings to styles, where the strings could be either types or identifiers. The style class could have in it stuff like color, font, bold, italic, etc. If I add in 2 styles like this: In the code window, I would get my code to be styled like this: thanks,
Jake

That probably won't fit in with our current token/language design however with v4.0 you can implement this sort of thing yourself if you get a little more low-level. For instance, you can create your own custom IToken and SyntaxLanguage classes, that when used together enable you to keep a dictionary of special words and then update the token's highlighting style based on that.

Thanks for the tip, is there an example how to do this mixed in with the c# language addin.

Unfortunately if you wanted to do it with the add-on, you'd have to purchase the source code for the add-on and modify our programmatic lexer, language, and token classes to accomplish this.

[Modified at 11/22/2006 09:04 AM]

I would rather not use your source code, as that would effectively branch me away from future updates you distribute. Instead, if you would just put my feature idea on your list and if you come up with a solution in the future, I would be happy to help test it.

thanks,
Jake

Hmmm... after looking at it, you might be able to do this in a tricky way now although it would probably impact overal performance to some extent. When the tokens are examined for display purposes in the C# add-on, they call CSharpSyntaxLanguage.GetHighlightingStyle and the token is passed. Now the thing is that you know the token info there but don't have access to the text contained by the token.

So you'd have to probably create a class that inherits CSharpSyntaxLanguage, override the GetHighlightingStyle method to implement your custom code. Also you would have to be able to set a specific Document instance to that language instance. Meaning that you could NOT use the language for more than one Document. But then if you had that, in your GetHighlightingStyle you could look at the text in the range indicated by the token and take action appropriately.

Unless you got our souce code as mentioned above or we came out with a much more elegant way to do this, that would probably be your only way to get it working with the add-on, even though it is a bit sloppy.

I'll add an item to the TODO list for this though and please feel free to post any other implementation ideas you might have.

[Modified at 11/22/2006 12:18 PM]

Hi,
I finally got to take a look at your suggestion. I think I can have a 1:1 relationship between language, but before I do that do you think it might be easier to either add in a text field or a document field to the IToken interface?

thanks,
Jake

We used to have that in old SyntaxEditor versions but it takes up 4 bytes of data for each token to do that and especially for large documents, that really adds a lot of memory usage.

One other possibility, maybe create your own class that inherits CSharpToken and override our language to create that. Then on your token class add a byte flag that can be set to indicate an alternate color. You could update that somewhere and then in the language's GetHighlightingStyle method override, look for those flag settings. Just an idea...