Re: opinion poll on text widget iterators

[Havoc Pennington <hp redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes: 
> // checks to see if an iterator is the same
> gint froo_tkxt_buffer_iter_comp(FrooTkxtIter*,FrooTkxtIter*)
> 

Just as a random note, qsort()-style compare is going to be relatively
expensive, but equality is super-cheap. (For equality, you just check
whether it's the same line and same byte offset; for compare, if the
lines are different you have to start futzing around in the btree to
see which is first.)

> See best of both worlds and no need for messy ref/unref and
> managing a dynamic buffer.  (Wow, that is actually cool, I
> wonder if we can use this to make a generic g_container) 
>

Nice, that is good to hear.
 

>         FrooTkxt_Iter& operator =(const FrooTkxt_Iter& iter)
>           { froo_tkxt_iter_copy(iter_,iter); }

Default operator= works fine, since you're guaranteed that there's no
allocated memory in the iterator.

For the public FrooTkxtIter I would have just:
 struct _FrooTkxtIter {
  gpointer dummy1;
  gpointer dummy2;
  gpointer dummy3;
 };

then cast that to my real object, of course.

> Why does it need to be O(n) the iter can have a pointer to a 
> structure?  (Note, if it is O(n) don't provide it, O(n^2) 
> use of this would just be too killer)
> 

See mail to Guillaume; it's O(n) because it's semi-robust.
You could add tags and marks while you are iterating, and you could
insert text on lines that come before or after the iterator.

However the loop as a whole isn't _really_ O(n^2), because n is not
the same in each case; the loop will be n steps, where n is the number
of characters in the buffer (probably in the hundreds of thousands),
the dereference will be n steps, where n is the number of segments in
the line, typically 1 segment for text with no attributes, and no more
than a dozen or so segments for a line in a typical font-locked Emacs
buffer.

> That shouldn't really be too big of deal.  You can make the
> darn thing large with plenty of expansion area and then change
> its size between major versions.
> 

OK, I agree.

Oh, I haven't told you guys about another problem: some iterators
point to embedded pixmaps or widgets instead of characters. Probably
the incr/decrement functions would just skip the pixmaps and
widgets. But then it might be nice to iterate over _everything_ in the
buffer...

Havoc