Re: iterator resolution

[Karl Nelson <kenelson ece ucdavis edu>]

> Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> > Is this checked in yet?  I was looking it over but couldn't
> > find where stuff was fully defined.  Also I could not build it
> > because the makefile was depending on GNOME being installed which
> > I don't have.
> > 
> 
> I've created a "broken" branch to finish it, because I will need to go
> between my work and home computers several times before it starts
> compiling again. Try cvs co -r broken but don't try to compile the
> broken branch. :-)

Hmm, my tkcvs didn't see the branch tag.  I will check it out later
then.


> The Makefile shouldn't have the gnome-config in there, just delete it
> and it will work.
> 
> (Clearly this Makefile is not intended for anyone but me...)

By the way, would it be alright if I refer to this frootkxt as 
Fruit Cakes? ;-) The sed friendly name is kind of a real tongue twister.


> Anyway, it's good that operator-- can be slow because I see no way to
> fix it without chewing up a good bit more RAM. On the plus side, it's
> not _that_ slow, it's just relatively slow compared to
> operator++.

As long as it is not O(size of buffer^2), slow it is fine.  Speed of
tranversing and speed of insertions are often competing 
qualities.  Balancing them so that traversing in one direction is
very fast and the other is reasonable is great.


> I do suspect that complicated text handling will generally be faster
> if you just extract the whole line as a string, then work with the
> string; if you were doing regexp matching for example I'm sure this
> would be the right way to do it.

Won't the incure a large dynamic allocation penalty?  Probably 
not significant for something was cpu and memory intensive as
a text buffer.


> A nice feature is that the string-extractor can place Unicode "unknown
> character" sequences in the string (or not, there are two functions). 
> What this means is that character indexes into the string match
> character indexes into the line exactly. i.e. unicode_strlen(str)
> equals the length of the line, even if the line contains pixmaps.

Sounds like a good feature.


> > Likely some memory can be shaved off of that, but I will
> > have to see it first.
> 
> Certainly you could shave it down, right now I'm figuring that caching
> information is more useful though. Since iterators aren't persistent
> objects, there will only be a couple at a time, really their memory
> use is no more important than the number of variables declared at the
> top of a function.

Most of the saving is just realizing the size of the magic numbers 
need not be 32 bits or some fields are never possible to use at
the same time.  But these are optimizations.  You shouldn't 
worry at all about the size until it becomes a problem.

> > end actually makes a lot more sense.  And iterator is just
> > like a cursor so where does one expect a cursor after you add
> > an item?  Intuitively it should be at the end.  If you want 
> > to keep in a spot, just add a mark and use it to return to that
> > spot.
> > 
> 
> Well, if conceptually we are thinking of the preserved spot as a mark,
> there are two types of mark: left gravity and right gravity. So the
> cursor is a right gravity mark; if you insert text at the mark, the
> mark ends up on the right. But FrooTkxt also allows a left gravity
> mark, that ends up on the left.
> 
> I'll register one vote for "insert leaves iter pointed after the
> text." I haven't decided which I like yet...
> 
> One thing I like about right gravity is that it makes it clearer that
> this is magic _insert() function behavior, rather than standard
> iterator behavior.

You could set have a gravity bit in the iterator if all else fails.

However, I think I should recast my vote.  The gravity probably should be
left gravity, but the insert function should always return the
"length" of the operation so that you can easily switch it the 
the other side....

   for (i=0; i<11; i++)
     {
       sprintf(tmp,"%d ",i);
       offset=froo_tkxt_insert_text(buffer, &iter, tmp);
       froo_tkxt_index_right(&iter,offset);
     }

"0 1 2 3 4 5 6 7 8 9 10 "
                        ^ 
                       iter

   for (i=0; i<10; i++)
     {
       sprintf(tmp,"%d ",i);
       froo_tkxt_insert_text(buffer, &iter, tmp);
     }

"10 9 8 7 6 5 4 3 2 1 0 "
 ^
iter

Of course, I guess it doesn't mater if it is right or left then,
but returning the offset makes it easy to do both without
using an expensive mark.  (as well as indicate failure to
insert anything.)  Best of both worlds if the return code isn't
currently used.


> Right, of course froo_tkxt_mark_new() will take a gravity argument, so
> you could do this same loop no matter which thing insert_text does (in
> this case it doesn't even matter since you insert the same string
> every time... ;-)

Minor point. :-)

> > That sounds good.  You should be able to create a named mark from
> > a iterator as well as an anonymous mark.
> >
> 
> Indeed, all the mark functions will probably have anonymous and
> _by_name() variants. _by_name() is just for convenience, so you can
> have several special named marks without having to keep global
> variables around or set object data.

Excellent.

   
> > >    The iter_insert() is shorter, but perhaps confusing, since it 
> > >    will result in a signal being emitted on the buffer, and is 
> > >    basically a buffer operation.
> > 
> > What is the value added for requiring the buffer?
> > 
> 
> Some kind of object-oriented conceptual cleanliness (basically that
> insert() should be a method on the buffer, not a global function).
> 
> After all, don't you do this:
>  vector<int> v;
>  v.insert(v.begin(), 10);
> 
> this seems a bit weird:
>  insert(v.begin(), 10) 
> 
> but this isn't that bad I guess:
>  v.begin().insert(10);
> 
> I don't feel strongly about it, would appreciate other opinions.

You are probably right.  Anything which mutates or acts the buffer as a
whole should take the buffer as an argument, but moving or altering the 
iterator by itself shouldn't require it.  I just didn't want to
see  froo_tkxt_index_word_right(buffer, &iter, 1);  as buffer 
really isn't involved.

--Karl