Make the TextView API more extensible

[LPeter1997]

Is your feature request related to a problem? Please describe.
Currently TextView only supports syntax highlighting through SetXXXColor(List<System.Rune> line, int idx) APIs, which doesn't even tell us what line we are on. This blocks 2 things in our use-case:

• Syntax highlighting for languages where tokens can span multiple lines.
• Highlighting the background of the currently executed statement in a debugger, which needs a line number.

Describe the solution you'd like
Expose all lines and the currently highlighted line index in some way. If the API was SetXXXColor(List<List<Rune>> lines, int lineIndex, int columnIndex), it would be a huge improvement and could technically solve both issues. Tho I understand that this isn't too nice of an API either.

Describe alternatives you've considered
I'm not familiar with other existing APIs that aren't too specific to syntax highlighting, so can't think of any.

[tznind]

This feature would be great.

I added the current syntax highlighting a while back but did it with as little modification of the view code as possible (TextView is 4000 lines of code 😱). It currently runs as part of render but I agree the solution is incomplete. One area of complexity is the WordWrapManager.

@BDisp maybe we could add an interface to TextModel that exposes only those public methods an API user needs for evaluating the content more comprehensively than just using Text?

interface ITextModel
{
   int LineCount {get;}
   List<Rune> GetLine(int line);
}

We could let user define syntax highlighting once for the whole ITextModel and then we hold onto that mapping and use it internally in TextView?

So TextModel would become something like:

class TextModel : ITextModel {
    List<List<Rune>> _lines = new List<List<Rune>> ();
    List<List<ColorScheme>> _colors = new List<List<ColorScheme>> ();


	/// <summary>
	/// Updates the colors used to render each rune in the given <paramref name="line"/>
	/// </summary>
	/// <param name="line">Line number in the source text (ignoring wrapping)</param>
	/// <param name="colorsByRune">Color to use for each rune.  Must match the number
	/// of runes on the line (see <see cref="GetLine(int)"/>)</param>
	public void SetTextColors (int line, IEnumerable<ColorScheme> colorsByRune)
	{
		[...]
	}

	[...]
}

It would be up to the user to register for TextChanged events, diff the old and new text and reassign colors for any changed regions?

We could make a helper class if that was onerous or had subtlties?

Or we could switch TextModel to using Cell instead of Rune for the data model. That way we wouldn't have 2 lists that could get out of sync.

[BDisp]

Or we could switch TextModel to using Cell instead of Rune for the data model. That way we wouldn't have 2 lists that could get out of sync.

This is a great idea. I'll explore it. Thanks.

[tig]

Cool!

As you dig into this @BDisp know I'm conflicted on Cell.

Should it hold a list of Runes? Or a string?

For ConsoleDriver all that's really needed is up to two Runes (there are no known combining marks that can't reduce down to two code points).

I also have considered the possibility that it could provide a place where keeping track of "to my left is a low surrogate" or "to my right is a high surrogate".

Please feel free to invent here!

[BDisp]

Cool!

As you dig into this @BDisp know I'm conflicted on Cell.

Should it hold a list of Runes? Or a string?

I'm considering as it is, although it was better the Rune wasn't nullable, but I'm workaround that. So it's better to be only a Rune. If two code points is needed then we use two Cell. That way is much more easy to manage with TextModel.

For ConsoleDriver all that's really needed is up to two Runes (there are no known combining marks that can't reduce down to two code points).

Alright we also are dependent on what each driver can do with that.

I also have considered the possibility that it could provide a place where keeping track of "to my left is a low surrogate" or "to my right is a high surrogate".

Isn't it the opposite?

Please feel free to invent here!

For now I'm leaving the Cell class as is and adapt all the code that use TextModel to handle with Cell.

[tig]

To be clear, I WILL be changing cell to use either List of Runes or a string...

[BDisp]

To be clear, I WILL be changing cell to use either List of Runes or a string...

Well that is now complicating my work :-)
TextModel works better with Rune. With a List I can managed it but with strings the code will be much more complicate. I'm really think to create a dedicate type for TextModel. I'm not advance more with this without we clarify what we really going to do.

[tznind]

To be clear, I WILL be changing cell to use either List of Runes or a string...

Well that is now complicating my work :-) TextModel works better with Rune. With a List I can managed it but with strings the code will be much more complicate. I'm really think to create a dedicate type for TextModel. I'm not advance more with this without we clarify what we really going to do.

I think its ok to make a new Type for TextModel. Its a 2 property class so no big deal to just have TextModelCell or something if it makes things easier.

Thanks for taking this work on @BDisp I think its gonna be pretty awesome.

[BDisp]

I think its ok to make a new Type for TextModel. Its a 2 property class so no big deal to just have TextModelCell or something if it makes things easier.

Thanks for taking this work on @BDisp I think its gonna be pretty awesome.

I think so too. I'll use RuneCell. That's ok?

[tznind]

I think so too. I'll use RuneCell. That's ok?

Sure that works. If its just for TextModel / TextView though you could go with TextViewCell or TextModelCell to avoid confusion with the existing Cell class?

Its up to you though.

[BDisp]

Sure that works. If its just for TextModel / TextView though you could go with TextViewCell or TextModelCell to avoid confusion with the existing Cell class?

Its up to you though.

Well, it will affect others views than TextView, like TextField, DateField and TimeField, besides RuneExtensions and StringExtensions. And a lot of others class. But I like the name RuneCell :-)

[BDisp]

Done. I think I've to add some more methods, like to get line at some index, but please review and then I'll add the missing methods. Thanks.