[Monodevelop-devel] Adding tracking spans in the MD text editor

[Mike Krüger]

Hi

> > *I want to move the discussion to the developer mailing list*
> >
> >> I had a talk with Michael Hutchinson on IRC regarding the new VS 2010
> >> text editor features, such as the text markers, tracking spans and the
> >> ITagger interface. I guess currently book keeping in the text editor,
> >> like region folding, bookmarks and breakpoints are done using markers.
> >> In VS 2010, changes in the text are exposed to tracking spans.
> >> Basically you create a span over some text, and after the text has
> >> changed, you can query the span for its status. They key difference is
> >> that, unlike markers that are checked at each text change event, spans
> >> are checked only when you require their status, ie lazy evaluation.
> >
> > Don't believe all of the ms marketing :)
> 
> I generally assume they know what they are talking about, but I'll be
> careful next time :)
> 

They know what they're talking about ... using an array for the markers
is a bad idea ... but I for myself are not very surprised about that :)
(I found that out about 10 years ago with my 1st text editor storing the
lines in an ArrayList :))

> > Monodevelop doesn't update all 'markers' on on text change events ...
> > Currently the stuff is stored in the line segments and the line segments
> > are stored in a red-black tree. And on text change only a small part of
> > the tree changes. The monodevelop text editor is the same in this regard
> 
> I did know about the line segment data structure, its used to
> calculate the LOC in the code metrics.
> I just had a vague recollection of it being stored in the RB tree.
> Thing is I don't know how to keep a track
> of changes in the line segment. Maybe theres a onLineSegmentChange
> event, I don't know. The problem is
> how do I narrow down to that *part* of the line segment that changed,
> ie a word or phrase.
> 

That's more difficult - I recommend storing the segments in a RB tree
and track the change there separately. 

> So would you suggest I create my own hybrid tree to keep track of text in the
> text editor? For example, I wanted to keep track of text that violate
> certain rules
> so that I could add little squiggly lines under them. I could probably
> create a tree
> that stores the links to the line segments that I know violate the
> rules. Thing is,
> is there a way to highlight only that part of the line segment which
> has the error?

Yes that's the current approach. The part of the line segment is more
difficult. The text marker gets the whole line. With this info you can
get the line layout and inside the pango line layout you have to get the
position of the line part with IndexToXY

> AFAIK, whenever theres a parse error, the entire line gets highlighted
> by a red squiggly.
> 

I'll improve the red squiggly lines when I get good parser errors. The
current ones are just 'proof of concept' :). NRefactory was never
designed for finding errors.

> > And I want to do an own red-black tree for segments (aka. 'markers') for
> > the highlighting. Currently the highlighting spans are a bit hacky.
> > Doing this as an own tree would be much easier. And a tree for semantic
> > highlighting tags as well. I think here something like the ITagger
> > interface would work. Currently the highlighting is state less more or
> > less ... the line segments contain the begin span stack. But I want to
> > get rid of this hack and have an own span red-black tree instead.
> 
> I guess this answers my questions above?
> Btw does this mean an RB Tree within an RB Tree?
> 

No it means just that each RB tree node (==line segment) has a tag with
the current span stack at this position. 

> > Overall I want to use more red-black trees in the text editor. Maybe
> > even put all markers into an own one (but for many markers the line
> > tagging works well and the line segments also aren't updated on each
> > text change). Currently the piece table has some bugs (but it uses the
> > same red-black tree than the current line segments, I haven't had the
> > time/patience to track this yet).
> >
> > It's interresting that the vs.net developers and we are doing almost the
> > same evolution - it's always good to know what the competitors are up
> > to :)
> >
> > If anyone wants to help with the text editor data structures (or maybe
> > have more proposals on doing things) - all input/help is welcome.
> 
> Um, make the text editor extensible through scripting? *ducks shoes*
>

Scripting for what ? (btw. we choose to be extendable with .NET using
the addin-tree :))

Regards
Mike