On Fri, Oct 31, 2003 at 11:14:14AM +0100, Alfredo Braunstein wrote: > Angus Leeming wrote: > > >> hasParagraphs is never used in the code, and we need numParagraphs > >> for having PosIterator/Cursor::operator-- > > > > Who could possibly object? Go for it. > > The ways of objections are misterious... ;-) I'll do it then. > > >> PS: should I drop PosIterator and try to make Cursor::operator++/-- > >> operative? > > > > Why not make PosIterator fully functional and then think about > > I'm doing this already: I think PosIterator in the patch I sent yesterday is > fully functional (the patch has some bugs in putting the selection at the > end of a successful search but that's another story). > > [Btw, it should be super easy to implement regex searches right? It would > suffice to implement operator* that gives pit->getChar(pos) if pos < size > and some '\n' if pos == size. In that way one could also search for > newlines etc. Methink.] > > > implementing Cursor in terms of PosIterator? > > My concern is that Andr� has already started implementing Cursor in his own > way, and maybe his way is better. [In any case, they are very similar I > think]. But I don't want to interfere with anybody's plans.
To be honest: Your ideas in this particular areas have not > If I could only get Andr� to comment what are his future plans on this... Sorry. Public holiday interfered ;-} >From what I can see now, your PosIterator should be usable as a base for a cursor, even if I'd prefer paroffsets at the beginning to make it easier to debug'. A cursor should either a pair (mathed-style) or a triple (outer world-style) of these iterators (one for the cursor poisition, the other one or two for the selection). The cursor belongs to the BufferView, so multiple views would mean multiple cursors. A cursor will have a few helper functions, most notably 'dispatch'. This dispatch() handles 'dispatch to the innermost inset able to handle an FuncRequest' as well as the replacement for inset unocking etc after FINISHED_RIGHT etc. Andre'
