Re: GtkSCText (was: Timescale issues)

[Derek Simkowiak <dereks kd-dev com>]

> This is probably way off target, but why doesn't someone with the time
> (and inclination) look at the guts of one of the semi-infinite numbers
> of editors out there and factor out the text engine one which is
> closest to what is required?

	I've done this.  The problem is that the only parts of these other
editors that are re-usable are the algorithms (which are fairly
well-understood already).  Most everything else in the GtkText widget is
Gtk+ specific.

	For example, it uses a Glib Allocator for memory, the Gdk library
for drawing to screen (and fonts/colors), a GtkAdjustment widget for
scrolling, Gtk+ signals for event handling, etc.  This stuff can't just be
pasted from another editor.

> I sort of like the idea of having access to a text widget which has
> more than simple display capabilities.  Program controlled editing
> could be quite nice.

	The new GtkText will have the ability to specify selections (and
do inserts, etc.), but the syntax highlighting should definately be left
out of the GtkText widget.

	Although we will eventually have a sub-class of GtkText that does
include syntax highlighting, the basic text entry widget should not.
Another problem with syntax highlighting is that all the Gtk+-based
implementations I've seen so far use regular expressions for the
highlighting, which is very, very slow.  Syntax highlighting should be
done using a customizable lexical scanner.  See Nedit, Code Crusader, or
(on Win32) TextPad for examples of this.

--Derek