Angus Leeming wrote: > Alfredo Braunstein wrote: >> [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.] > > Great idea. > > ... it would returns 0 if no match is found.
Me not understand. Are you still talking about PosIterator::operator*() ? I thought simply that if we can make PosIterator like a normal char iterator in some way, then we can use some standard regex library... (you probably know exactly how and which, I don't) > ... how about it returning META_INSET if you're searching for an > inset of a particular 'flavour'? That's another thing that would be interesting: search for specific insets. One thing that needs to be think of is how the user would specify the inset type. The current implementation of PosIterator goes first to the inset position, then inside it. I don't know if this allows for all desirable complexity on search strings (I don't know if it's so suitable to search for "'foobar' inside a table" for instance. Hum... maybe yes). > Why not produce a rationale description of the differences between > the two, where one is better than the other etc. Seems that Cursor caches the insets and lyxtext on the path. It currently also uses paroffsets that are a bit slower. In any case, if the things I need gets implemented on Cursor, I imagine that we can simply substitute all PosIterator by Cursor and we are rolling... Regards, Alfredo
