Re: opinion poll on text widget iterators

[Havoc Pennington <hp redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes: 
> By the way there is a really cool way to keep caches so that 
> you can avoid the O(n) problem.  You place an int in the
> class and the iterator.  Every time a change is made to the 
> class you increment the int.  The iterator keeps a copy of 
> this int in itself so that if can match the item.  Then when you go 
> to use the iterator you can check to see if the iterators cache
> is up to date with the current widget.  If it is use it, otherwise
> use the O(n) to get the data.  Since it is unlikely that you
> are going to have too many iterators walking through the 
> class changing things, this provides a very fast and robust
> way of handling things.
> 

An intriguing idea, I'm going to investigate doing this.

>  
> > 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.
> 
> Be sure to place the object pointer in there itself so that we
> don't have to lug it around.  It is okay if it breaks if the
> iterator is held through the deletion of the widget as iterators
> should only be local in scope.  I like my iterators to be
> useful outside of the most basic uses.
>

Yep, it has that.
 
> 
> Also if you want to be really special you can place a class
> pointer in the iterator.  The iterator could be made to 
> then be abstract and skip items.  Thus you make an iterator
> which jumps from picture to picture or char to char and 
> all have the same size.
> 

I have about 57 ways to move the iterator right now (next_char,
next_word, end_of_line, next_line, up_line, down_line, find_backward,
find_forward, etc.)

So next_pixmap is just another one of these. For C, I don't want
different _types_ of iterator, because you want to be able to go
forward a word, then down a line, then to the next pixmap, keeping the
same iterator.

For C++ you could simply have various subclasses where operator++
called different iterator movement functions, right?

> > 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.
> 
> Does my time stamp solve that problem?  

Yes it does.

> If CList/Ctree/List and
> others had this mechanism then we could aggressively cache the
> tail pointer, and I would stop my incessant whining about the
> tail pointers.
>  

Note that my lines of text are thankfully not in a linked list, so
there's no point in tail pointer caching for the text widget.
 
> Actually we have been handling that better than gtk+ in most places.  
> I just rewrote the CList wrapper so that it handles the 
> 4 data types in a unified manner.  Thus rather than having a 
> 
>   set_text()
>   set_pixmap()
>   set_pixtext()
> 
> I switched to
>   clear()
>   set_text() 
>   set_pixmap()
> 
> And make it so that if you change the type it will just place change
> the current type to one which has both.
> 

I don't _think_ this applies to the text widget - basically an
embedded pixmap or widget is just a funky character, it can be deleted
with backspace, you can insert before/after it, etc.

I guess you could have an iterator_assign() function that deletes
whatever's at the current iterator and places new text or pixmap there
instead.

Havoc