Re: Gtk::Text widget

[Derek Simkowiak <dereks kd-dev com>]

-> I created a Motif text widget about 5 years ago that uses UTF-16 (aka UCS-2)
-> internally exclusively.

	UTF-16 is a multibyte encoding, where characters can have either 2
or 4 bytes.  If you only used 2 bytes per char *every* time, then you were
using UCS-2.  UTF stands for "UCS Transformation Format", i.e., a way to
put the full 32-bit Unicode character set into a multibyte transformation.
	
-> attributes), and after many moons of experimentation, I ended up using 4 bytes
-> per character, with 2 of them acting as an index into a table of attributes
-> (color, font, etc..).

	This is what Nedit does, too (although I think it only uses 1 byte
per char, i.e. ASCII).  You're limited to about 65 thousand different
attributes, but that shouldn't be a problem (it was a problem for me when
I was considering the Nedit method, i.e. only 256 possible different
attributes)

->  Tagging each character with attributes turned out to make things a
-> lot easier to manage than coding to deal with parallel attribute
-> structures as you find in Emacs or breaking things into a tree as in
-> the TkText widget.

	Yes, but I've already done the coding for parallel attribute
structure (a list of Lines that holds a list of spans), so I'm going to
get the "View" working before I make any drastic architecture changes.
Also, I want to store information about lines (so particular line numbers
can be marked with "bookmarks", or with an "error"/"warning" icon in a
GUI debugger).

	I am currently in the process of separating out the parallel
attribute structure into a module of its own (...lack of foresight on my
part...) so that I can later replace it with something faster, if it turns
out to be a bottleneck.

	I think of my widget as structured in layers, like in the Gimp.
The bottom layer is the gapped text buffer, the next layer up are the
"Style" spans (which are optimal for scanner-based syntax highlighting).
The third layer up will be overlapping tags, in a tree structure, once
I've had time to write it.

	For now, though, my focus is just on getting a View working with
Pango...

-> And adding regex wasn't difficult with a gap buffer.

	(This is why I'm using a gapped buffer :)



--Derek