Re: What's the "Hangul shaper"? Sounds like a power tool...

[Havoc Pennington <hp redhat com>]

<skip pobox com> writes:
>     >> (well, the TextBuffer object is broken IMHO and always contains at
>     >> least a carriage return)
> 
>     Havoc> This is a Broken On Purpose - even documented to work the way it
>     Havoc> does, IIRC. I agree it's broken, I've known about it for half a
>     Havoc> year, Tk is broken in the same way - and it's just really hard to
>     Havoc> fix, and so we are declaring the bug a feature. I can't really
>     Havoc> justify spending a week on changing this behavior. :-(
>  
> I don't suppose there's a bug filed against this that describes the problem
> and why it's not easily fixable, is there?  I never have much luck searching
> bugzilla.gnome.org.  Generally the only response I get to a search is "Zarro
> boogs found".
> 

There are about 300 glib/pango/gtk bugs in bugzilla, so you need to work on your
search technique. ;-)

Anyway, this bug isn't in there.

The cause of the problem is that the text widget data structure is a
btree. Each leaf of the tree is a newline-terminated line of text
(well, in current CVS, theoretically the line can also end in \r, \n,
\r\n, or 0x2029). Anyway, they are lines.

Because of the nature of the btree data structure, there must be at
least two nodes. So, the way the Tk widget was designed (and I
inherited), one of the two required nodes is the "magic newline that
isn't really in the buffer" and the end iterator is on the start of
this line, and the other node is the newline you can't ever delete.

Pretty lame isn't it?

So the problem is that the btree code is pretty fun stuff. It's not
badly-written code, but it has some inherent complexity. I've hidden
this a good bit with GtkTextIter, while in Tk all the buffer code
would just wander around in the btree directly, but there's still a
good bit of direct wandering around in the btree sort of code used to
implement GtkTextIter and other things.

I think the fix is more or less to say that both required btree nodes
are "fake lines" and don't really exist in the buffer, and the
iterator is at the start of the first required node, rather than at
the start of the second one. So there should be two magic bogus lines,
and the second one doesn't even store the end iter, it's just
completely useless.

Looking at it now, it doesn't seem that hard to fix, but I already
spent a day or so on it and remember that it was looking darn hard.  I
don't remember what the catch was. I think there's just quite a bit of
code that makes implicit not-very-obvious assumptions that it works
the way it currently does, and you have to find all those.

If you want to give it a try, maybe it's not all that bad. I'm even
tempted to try it again since I don't remember what was making it hard
before, and I could at least try to find the problem again for
historical interest. ;-)

Havoc