Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
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.
No, I was really thinking about your begin DocIterator described below.
- 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).
My idea would be to let Paragraph::find() recursively descend into
nested Inset and Paragraphs. That's why we would also need the same find
method for InsetMathNest.
But we could also just navigate using DocIterator as you suggest. But I
wouldn't use DocIterator for navigation at pos_type level, only for
pit_type navigation:
DocIterator find(
DocIterator const & begin,
DocIterator const & end,
Paragraph const & searched_par)
{
DocIterator it = begin;
begin_pos
while (it != end) {
pos_type begin_pos = it->pos();
Paragraph const & par = it->paragraph();
pos_type const found_pos = par.find(searched_par, begin_pos, ...))
if (found_pos != -1) {
it->pos() = found_pos;
return it;
}
it->forwardPar();
it->pos() = 0;
}
return end;
}
'it' will point to end if nothing was found.
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...
I am not sure I understand the question but FYI
DocIterator::forwardPar() takes care of navigation inside nested Inset.
- 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.
How would you do the UI? Insertion and deletion are automatically marked
in the main work area but you'll need special marking method in the
embedded one. Or would you just do that via cut&paste from the work
area? This is pretty advanced stuff anyway...
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.
OK, I simply forgot about regexps. Then, instead of returning this
length, I would probably return two DocIterators.
Abdel.
