Indicator events

Hello,

You are right in your thinking and a tagger like BreakpointIndicatorTagger will get injected, allowing you to watch TagsChanged.  The only caveat is that it doesn't get installed until the first indicator of that type is added.  That is done for performance reasons so that there aren't unnecessary taggers in place.

OK I understand, but what do you suggest ?

Hmm... what if you do this sort of thing on your language:

language.RegisterService(new CodeDocumentTaggerProvider<BreakpointIndicatorTagger>(typeof(BreakpointIndicatorTagger)));

Is the tagger available to you then once the UI has been instantiated?

If not, you could also force it to create the tagger with something like this:

var tagger = taggerProvider.GetTagger<BreakpointIndicatorTag>(document) as BreakpointIndicatorTagger

In that, taggerProvider is the tagger provider instance you registered on the language.

Thanks, actually, it works when I add or remove a breakpoint (with the method IndicatorManager.Breakpoints.Toggle), the event TagsChanged is raised.

But when I remove a text containing one or more breakpoints the event is not raised and when the breakpoint is moved from a line to another, the event is not raised.

What is the easiest way to manage a breakpoint list ?

Hello, yes that is correct since for a CollectionTagger (which is what the indicators use), the TagsChanged only fires if you call into the indicator (or lower level tagger) API to alter the collection.  The TagsChanged event doesn't fire in the case where a text deletion occurs that ends up removing tags since we actually don't detect that scenario until tags for that deleted range are collected (such as by a UI refresh for that range).  Normally if you delete text that contains an indicator, the UI is already being refreshed over that range, so if we fired another TagsChanged event then it would trigger another UI refresh that is unnecessary, thereby degrading performance.

I agree that this is a bit of an inconsistent scenario.  We have to consider that collection taggers work a bit different from other taggers though.  In collection taggers, we are holding a fixed list of tags.  In other taggers, they are completely virtualized, and only do tag lookups on demand to improve performance.

We don't have any events for when the tagged regions "translate" to new snapshots, which may or may not slide them around the document depending on the text change between snapshots.  That translation also only occurs on demand, when the tags are requested.

To work around the issues here, what if you did something where you had a separate list of breakpoints and their ranges.  Then you handle TagsChanged like now but also the DocumentTextChanged event.  In both handlers you get the breakpoints again, and see if any have changed (added, removed or translated).  I think by doing that, you would get all the notifications you need.

OK I was expecting a better solution ;) but I understand your point of view, thank you for your explanations.

I should have also mentioned that we added an item on our TODO list to try and add events to the collection tagger for add/remove/move, which might help in the future.