WPF source editor and extensibility
-
Saturday, December 20, 2008 1:10 PMReally liked the ScottGu (I think) demo of a new visualization of XML comments that would appear directly in the source editor.
This raised a lot more questions - what kind of things can I register such an extension to deal with? Could I, for example, provide a visualizer for expressions of a particular type? It strikes me that this is like supporting embedded DSLs with visual editors. It's a very exciting, powerful idea. Could I provide a visualizer for editing string literals, which automatically hides all the details of escaping? Or do the equivalent of XML literals, all with custom editors?
If this kind of extensibility was capability of associating new GUI elements with particular patterns in our code, then it would be just like having a totally extensible language (with the underlying C# language as the reliable lingua franca behind the scenes).
Or is it only going to be able to deal with a few coarse-grained predefined things?
Also, does the custom visualization have to take up exactly the same amount of screen real estate as the underlying code? I noticed that was the case for the XML comments demo. Seems limiting if true.
And will it gracefully deal with two extensions trying to handle the same thing?
--Daniel
Answers
-
Friday, January 23, 2009 11:06 PMModerator
The extensibility of the New Editor is actually quite powerful. If you as an extension author can determine what code you want to replace with an Adornment then the New Editor makes it easy for you to do that. Providing visualizers for string literals is one of the cases that we hoped to support and through classification it is likely that you'll be able to easily find the string literals as provided by the language service.
The demo itself required that adornment obscure the text since we aren't completely finished with the new editor extensibility model but we're working towards the point where you can replace arbitrary text.
Throughout much of our new API there is a concept of Order which allows an extension to specify their location or order with respect to another(including the editor components themselves). We also have space negotiation so that adornment can avoid overlapping even if they don't know about each other.
Thanks!
-Sean Laberee
VS Platform Team
Program Manager - Visual Studio Editor & Code Navigation Team- Marked As Answer by Daniel Earwicker Thursday, February 05, 2009 1:35 PM
All Replies
-
Friday, January 23, 2009 11:06 PMModerator
The extensibility of the New Editor is actually quite powerful. If you as an extension author can determine what code you want to replace with an Adornment then the New Editor makes it easy for you to do that. Providing visualizers for string literals is one of the cases that we hoped to support and through classification it is likely that you'll be able to easily find the string literals as provided by the language service.
The demo itself required that adornment obscure the text since we aren't completely finished with the new editor extensibility model but we're working towards the point where you can replace arbitrary text.
Throughout much of our new API there is a concept of Order which allows an extension to specify their location or order with respect to another(including the editor components themselves). We also have space negotiation so that adornment can avoid overlapping even if they don't know about each other.
Thanks!
-Sean Laberee
VS Platform Team
Program Manager - Visual Studio Editor & Code Navigation Team- Marked As Answer by Daniel Earwicker Thursday, February 05, 2009 1:35 PM
-
Thursday, February 05, 2009 1:34 PMThat sounds absolutely amazing. Looking forward to a new build to play with.

