Re: [gtk-list] Re: Glib's trees and FYI: TkText widget

[Derek Simkowiak <dereks kd-dev com>]

> But IMHO \n's themselves are outdated.  They are a thing of 80x25 text
> terminals era.

	Not true.  Visually, yes, in today's WYSIWYG world \n is not a
good indicator of when to linewrap.  However, this is a text widget, not a
word processor.

	When a program compile fails, gcc (or perl, or wish, etc.) tells
you what line number the error occured on.  When you debug a program with
gdb, you set the breakpoints by line number.  'wc' reports lines based on
\n, and some companies use lines of code as a productivity indicator.  
diff, RCS, CVS, all these things depend heavily on the good ol' \n.

	I want my application to be able to display the current line
number (by \n count), and to be able to create diffs, etc.  All that
requires an easy system to handle a "line".

> Not exactly. BTree is simply a container. Nothing more. It's used
> because of it's speed. And as any container, it can have an abstracted
> interface through which to be talked to. Just think carefully what
> operations you want from this data storage and write interface 
> functions.

	I still believe having the 'segments' within the BTree is a bad
idea.  Complicated code, even when hidden behind a clean API, is still
difficult to maintain.

> This is a question of memory management. It makes no difference where 
> you keep your data. What matters is sizes of pieces and how often you
> reallocate them. Malloc is the Great Equalizer :)

	I guess my question, then, is specifically about the GAllocator
and how it interoperates with the Glib n-ary tree.


--Derek