Re: Gtk::Text widget

[Havoc Pennington <hp redhat com>]

[The reason to continue this thread is to clarify the GTK widget's
design decisions, I don't think there's a "right answer" really.]

Derek Simkowiak <dereks@kd-dev.com> writes: 
>   if (active_window_stack)
> 
> 	...and "if", "("/")", and "active_window_stack" each have their
> own color, that's 4 * 80 bytes per on/off tag pair, so 320 additional
> bytes on top of 25 bytes worth of text--not counting the additional
> line/tree overhead used to store the text.
> 
> 	I'd consider that a memory hog.  Am I missing something?

I differ philosophically; "memory hog" means more memory than a
feature set is worth, and so if your max memory for a typical 50K-100K
source file is well under an amount of memory you will notice on a 32
meg machine, then I don't see any hogging. The GTK widget has some
memory optimizations vs. the Tk widget, and people have used the Tk
widget in many applications.

Especially if keeping the memory down requires a speed hit for many
common operations, which is what a gapped text buffer does. Emacs can
get away with this by having totally broken scrollbars, among other
things. You are also going to end up with caches left and right, which
will use memory. In general the gapped buffer makes the application
author worry about the internals of the widget to avoid performance
problems, and the tree from TkText makes the widget just be fast
enough almost all the time.

Even the worst-case instance you mention above (lots of tags with few
characters) is 320 bytes plus 24 for the line header (your 80 bytes
per pair includes the char segment headers), or 344 bytes, means 14
bytes per char. For a 50K source file that is 700K in the process. 
50K is a huge source file. And there is no unmeasured overhead here
such as caches (the tree nodes are negligible). If you take a file
with 40 bytes average per line, then you get only 8.6 bytes per char
or a 430K in-process; with 80 bytes you get 215K for the 50K buffer,
or about 4 bytes per char, exactly the same as a UCS-4 gapped buffer
with no properties. Add the properties, or look at a UCS-2 buffer with
properties, and you have similar memory to the Tk-based widget with 80
column text. UCS-4 with properties probably uses more than the Tk
widget in this case.

So, IMO this is good enough for a programming editor.

A gapped text buffer is also good enough for a programming editor, but
it's not going to scale to huge files, it isn't UTF8-friendly, and
many operations can be slower or more difficult or less flexible than
they are for the tree-based widget. For example a search for all
characters with a given tag will be quite fast with the tree, and
either slow or memory-hungry with the gapped buffer.

Anyway, the text buffer is more general-purpose for these reasons. If
all you want is color highlighting for relatively small files, a
gapped text buffer is a good optimization, but you give up a lot of
programming convenience, and it isn't general-purpose.
 
> 	Somebody posted a Glib-ized regex to the list a few weeks ago, and
> it got some feedback and went through a couple of iterations.  Is there
> any reason not to add it to Glib?  I think it would be very useful to
> have.
>

No Unicode support.
 
> 	I've seen several emails (including today) between Tim and Owen
> discussing different filenames for concurrent installs; since they haven't
> finished that work yet, I assumed it was best to wait until they had it
> straightened out.
>

It works now, just discussing changing it.
 
> 	Is there are How-to/FAQ about developing with concurrent versions?
> How do you have your environment set up?  What does your /etc/ld.so.conf
> look like?  What option must I give to ./configure?  Etc.
> 

There's no need to do anything, just replace AM_PATH_GTK with
AM_PATH_GTK_2_0 and gtk-config with gtk-config-2.0 and it will work.

Use the RPMs for safety.

Havoc