Re: iterator resolution

[Havoc Pennington <hp redhat com>]

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. :-)

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...)
 
> operator -- being slow is not that big of deal.  I suspect line
> up and line down are equally slow.
>

Yes - well, anytime you find a point in a line you have to scan the
line linearly, since lines are just linked lists. The head of each
line is in the tree though, so you can move from anywhere in a line to
the _start_ of the next line with a simple line = line->next within a
tree node, and a line = line->parent_node->next->children (with a
variable number of parents you have to go up, of course) works the
rest of the time.

Previous line involves going up to the parent node and scanning from
the first sibling line up to the previous line.

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++.

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.
  
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.

> >  - iterator objects are kind of large, something like 40 bytes;
> >    I don't think this matters, usually you only have 1 or 2 of them
> >    at a time.
> 
> 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.
  
> >    An outstanding issue is what we re-init the iterator to point to
> >    (start or end of inserted text, end seems like it might be more
> >    useful but start seems more intuitive).
> 
> 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.

>   FrooTkxtIndex iter;
>   FrooTkxtMark  *mark;
>   ...
>    
>   mark=froo_tkxt_mark_new_index(&iter);
>   for (i=0; i<10; i++)
>     {
>       froo_tkxt_insert_text(&iter, "hello");
>       froo_tkxt_index_at_mark(&iter,mark);
>     }
>   froo_tkxt_mark_unref(mark);
>

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... ;-)

> 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.
  
> >    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.

Havoc