Does the SyntaxEditor .NET Languages use Roslyn?

SyntaxEditor .NET Languages Add-on for WPF Forum

The latest build of this product (v24.1.2) was released 3 months ago, which was before this thread was created.
Posted 26 days ago by Joseph Albahari
Version: 24.1.2

I presume the answer to be 'no', due to its C# support ending at version 9, and it not tokenizing interpolated strings.

If not, can I ask why not, or more specifically: are there any special problems I would encounter in implementing a Roslyn-based SyntaxLanguage?

I did the same for the old WinForms SyntaxEditor many years ago, and Roslyn's lack of a lexical tokenizing stage didn't play well with ActiPro's synchronous token-based syntax coloring system - I ended up with an inefficient system that converted the Roslyn syntax tree into a stream of fake tokens to make it work. However, it appears that the new WPF editor supports a pull-based approach for syntax coloring, without the use of tokens, and that an implementation of `TaggerBase<IClassificationTag>` can efficiently feed the editor with classifications directly from a Roslyn syntax tree.

Are there any other potential issues I should be aware of?

Comments (2)

Posted 23 days ago by Actipro Software Support - Cleveland, OH, USA

Hi Joseph,

The .NET Language Add-on can optionally use Roslyn to load reflection-like metadata for binary assemblies, but it doesn't currently use Roslyn in any other way.

The newer SyntaxEditor model still does work most efficiently for syntax highlighting if you have a lexer tokenizing spans of text for the requested view line ranges being rendered, since those tokens then return classification types for the tokenized ranges.  But you can override syntax highlighting for text ranges using the tagger you mentioned.  You certainly could give it all a try and we'd love to hear the results.

Actipro Software Support

Posted 22 days ago by Joseph Albahari

I've tried running a prototype with 50k LOC in the editor and performance is excellent so far. A delay of around 300ms occurs when you make a change that requires the entire tree to be re-parsed, such as removing a /* comment token from the start of the document, or executing/undoing an operation with >1000 changes. However, this delay becomes almost unnoticable if you update the SyntaxTree asynchronously, using the previous syntax tree to feed the tagger until the await is complete. I'll keep you posted.

Add Comment

Please log in to a validated account to post comments.