Structure matchers and dynamic child languages

Hi Kasper,

Your two options would be:

1) Make an uber structure matcher that knows how to work with the root language and each child language's tokens.  Then regsiter that on the root language.  That is the easiest and fastest thing to do.

2) Design your individual language structure matchers such that they stop when they encounter another language.  In the options object you pass each one you'd need to potentially pass a "state" object of some sort.  And the in the result set object you pass back, you'd need to return a "state".  Thus if a child language breaks because it detects another language, it would need to pass its state so that that state could be used then next time that child language is encountered in the same matching session.  Then you'd need a wrapper structure matcher to sort of coordinate all this.  You can see this will be complicated so I'd highly recommend #1 instead.

For tag matching you can have your structure matcher look at the document's parse data to get the AST and base your matches on that.  Since the parse data could be out of date (while multi-threaded parsing is still occurring for the most recently typed changes), I'd recommend you always translate the offsets from the AST from their source snapshot to the current view's snapshot.  The other option is to go purely with a token scanning design where you keep a stack of the tag names you encounter, etc.

Okay thanks, I will look into the "uber structure matcher" :)

About highlighting HTML tags: I have all the information needed to highlight the matching tag in my own code (offset, length and so on), since that was what I had to do in SE for WinForms. So what I really need is a replacement for the ViewBracketHighlightingUpdate event that works for the WPF version. Can you point me in the right direction? 

Hmmm we don't have anything like that any more.  Basically in 2012.2 we added a custom tagger for the new IDelimiterHighlightTag interface that watches for document, text, selection changes, etc. and after certain events it starts a quick timer (about 100ms) to see if other events cycle through.  That's useful in helping reduce unnecessary scans when the user is scrolling or typing really fast.  Then we fire off a structure matcher request using the worker threads that parsers use.  When we get the result we update the tags on the tagger.  It's a fairly complicated setup internally but works great.

If you have all your tagged ranges known, then what you should do is simply make a custom tagger for IDelimiterHighlightTag and update your tagged ranges when your data updates.  You may want to introduce a quick delay like we do for perf reasons but that should accomplish the same thing.