Re: Gtk::Text widget

[Mark Leisher <mleisher crl nmsu edu>]

    Havoc> Of course UTF8 ruins the benefits of a gapped buffer, so you don't
    Havoc> want to use it there. This was one reason to avoid the gapped
    Havoc> buffer design.

Quite!

    Havoc> I guess you could have the number represent a list of properties,
    Havoc> but then you're starting to talk about more complexity and memory
    Havoc> usage.  You could also start needing more than a 16-bit number
    Havoc> fairly quickly.  (Properties stored in the Tk buffer include color,
    Havoc> size, font, overstrike, underline, background, custom key and
    Havoc> button event handlers, word wrap, editability, margin, space above
    Havoc> and below lines, visibility of the text, language the text is in,
    Havoc> justification, super/subscript, and any random metadata the user
    Havoc> associates with a given tag.)

Well, many of our applications use many more properties than this.  Negligible
impact on performance, but it chews up memory.  My 16-bit "attribute code"
simply points to a unique set of properties.  A single set of properties can
be huge in some cases, but the number of unique property sets tends to stay
relatively small.

    Havoc> It's O(n) in the length of the buffer to search for a property, and
    Havoc> O(n) in the length of the region being affected to add or remove a
    Havoc> property.

Same here.  Searching for some arbitrary combination of properties as well.

    Havoc> The gapped buffer also presents problems if you want to allow
    Havoc> embedding of images, widgets, marks, etc. in the buffer; most of
    Havoc> these have to be stored separately, instead of in the buffer
    Havoc> itself, and this creates a series of data structures you have to
    Havoc> keep in sync = maintenance headache, speed hit, and memory usage.

I agree, this is a big problem with gap buffers.

    Havoc> All the gapped buffer implementations I've looked at (Emacs,
    Havoc> kwrite, GtkText) lack these sorts of features. It would be
    Havoc> interesting to see the XEmacs gapped buffer though (I assume it has
    Havoc> one), since there are more features there. I'm not sure if they
    Havoc> fixed the scrollbar though. ;-)

I'll never understand why they got the scrollbar wrong and for so long.
Although it did take me a lot of time to figure out exactly how simple it
really is.

    Havoc> Anyway, I expect the ease of use and expressive power of the
    Havoc> tree-based widget to be the most interesting aspect of it.

It will be fun to play around with.
-----------------------------------------------------------------------------
Mark Leisher
Computing Research Lab            Once you fully apprehend the vacuity of a
New Mexico State University       life without struggle, you are equipped
Box 30001, Dept. 3CRL             with the basic means of salvation.
Las Cruces, NM  88003                            -- Tennessee Williams