XPath Syntax Hilighting - Where Are We? (reposted)

Long-time readers of my weblog (HAHAHA) will probably remember the fun I was having some time ago writing an XPath syntax hilighting tool. So what happened to said tool that showed so much promise (more laughter)? Well, the story goes something like this:

Round-Tripping White Space In Hilighted Expressions

I hate developer tools that re-format your code on you, so I was determined to create an XPath expression tester that didn’t do this to others. I had to throw out my existing syntax hilighting code and re-write (using the XPath parser/scanner in the SSCLI ROTOR as a base).

Hey, Wouldn’t it be Cool if Instead of Showing the Xml Document as a Yucky Tree-View it was Syntax-Hilighted Text That You Could Edit

More proof that adding features is dangerous - this one has led me down another rabbit hole. I started from scratch using the RichText control in windows forms, and built up an in-memory object model of my rich text document as I parsed the Xml with a reader. I then turned the in-memory representation into a rich text string, which I then loaded into the rich text editor. Editing the rich text editor marked the rich text as “dirty“ and when the application idled it would do a re-parse/document generate RTF generate/display. While seeming good in theory and working for small to medium sized documents this approach sucked badly for large Xml documents. I guess when I think about it this is unsurprising, I was doing something like string (xml) -> parse (Xml Reader) -> Xml Dom + in-memory Rich Text “document“ -> RTF string -> parse (inside rich text box) -> in memory Rich Text “document“ (inside RichText editor) -> display. I made some performance tweaks here and there, but this approach was flawed. Also I found it hard to think about a way of doing this in a multi-threaded manner, because most of the work (roughly 90%) was happening on the main UI thread (inside the rich text editor).

Where to Now?

This leaves me with one question - where to now? I could release what I have and get on with my life, or take one of the three options:

1. Continue writing my own Xml editor, by progressively rendering the document using the Select/SelectionColor methods of the Rich Text box. Ignore the great work the visual studio team have done on the Xml editor in VS 2005, and soldier on. Maybe by the end of the year I can be where VS 2003 is now.

2. Write a visual studio add-in. Leverage the good xml editor in VS.NET 2003/great xml editor in VS 2005. The only thing I think I would need to do that I couldn’t find an example of is modifying the colour/boldness of a piece of text in the Xml document. Sadly this does not seem possible. I’d even settle for squiggly underlines like this add-in (using CodeRush’s DXCore, but still running inside Visual Studio) is able to do. Resharper is able to do lots of special syntax hilighting, but they’ve made so many changes to the text editor I’m not sure if it is even Visual Studio anymore. Is VSIP the way to go for this sort of thing?

3. Use somebody else’s syntax hilighter. This managed version of Scintilla looks capable of some nice things.

Update: I’ve signed up with VSIP and downloaded the SDK.


Hi, Joseph.

Is it really impossible to highlight VS 2003
C# code fragment?
I have this problem, but i’m a beginner in add-in writing.
25/06/2005 4:03:00 AM
I’m always reluctant to say "impossible" but I found quite a few fairly conclusive statements saying it was not possible. VSIP seems to offer you a way via Custom Text Markers http://blogs.msdn.com/dr._ex/archive/2004/6/9.aspx

I’m pretty new to all this myself and still trying to find out what is possible.
25/06/2005 3:28:00 PM
levon chang
Hi JCooney :

In your post, you said your new version XPath Expression Tester using XPath parser/scanner in the SSCLI ROTOR as a base.

I’m very interested in how these classes usage.
Can you give me some example or somthing hint? please…

send me a mail : [email protected]
very thanks..
18/07/2005 6:59:00 PM