Abdelrazak Younes ha scritto:
Yes, passing a paragraph was exactly what I had in mind. That's why I
call that binary search ;-)
Aha ! Presenting this term together with the "acrobat-like" stuff, and
the performance issue,
I was thinking instead that this term referred to a binary search in the
sense of logarithmic
search rather than linear search :-)
We may also need to have a specialization for math only searching, or
by inset type searching.
IIUC, Paragraph would register itself in the passed DocIterator,
right? We may also want to start from a given position inside the
paragraph (0 by default).
I assume you're talking about the Paragraph supplied as the search-text.
Don't know when this might be useful, however, if it is easy, then we could
add a start pos for this as well.
- begin and end DocIterator (i.e., search restricted to a selection)
No, I would only pass the 'start' and 'end' pos_type which would by
default be 0 and size().
The original motivation for having a full DocIterator is the following:
1. I start searching with something like:
Paragraph const & search_par = ...;
begin_dit = par.begin();
end_dit = par.end();
if (par.find(begin_dit, end_dit, ..., found_dit, match_length))
{
... use found_dit, i.e.: putSelectionAt(found_dit, match_length) ...
}
2. when I need to keep searching, I can simply do:
begin_dit = found_dit
if (par.find(begin_dit, end_dit, ..., found_dit))
... and easily keep searching from where I left off last time
(and I can do a preliminary found_dit.forwardPos() before calling).
How does this (quite simple, IMHO) usage paradigm change when
you can only specify a start-pos ? Then, you need first to manually
identify the nested paragraph or inset in which the previous match
occurred, then handling all nest-exits etc...
- search direction
- how to deal with changes and deletes
Addition should be searched of course and deletions should be ignored.
In the future we could probably add a method to search deleted text,
but that is not a priority now IMO.
What about having it behave like it appears on the screen ?
If you are displaying changes, then you should be able to find
them, otherwise not.
The return type as DocIterator pos and match_length aims to provide the
exact (possibly inset-nested) position where the found text is,
and what is
the match length starting from there.
I don't understand this last point.
The match length is not necessarily search_par.size() when you have regexps,
so I need to know what is the length of the matching text, in order to
issue the
subsequent putSelectionAt() -- see example above --, or to replace the
matching
text.
Now multi-par search (if one wanted it) would have to be managed
externally
anyway, or inside a Text::find().
Yes. But using new Paragraph::find() of course.
of course :-)
Bye,
T.
