Abdelrazak Younes wrote:
You can use the paragraph id and the position in that paragraph. Else
there is the StableDocIterator IIRC.
I can see operator<<() but not operator>>(), both for StableDocIterator
and for CursorSlice. I guess the operator<<()s are there just for
debugging purposes, not really for serializing and deserializing back
those values. Also, this serialize/deserialize burden only arises
because, in order to use an LFUN, I have to provide all arguments as a
string as the LFUN argument.
I'd suggest GuiApplication and I'd also suggest to find all occurences
in one go instead of searching Buffer per buffer one search at the
time. Then one could easily imagine a dockwidget similar to the
outline panel that will link to all found occurences accessble through
a simple mouse click. That would be powerful my friend! :-)
If we searched for all occurrences in one go, then the operation would
take too much time, and it would really be mandatory something like an
LFUN call performing *incremental search*: each time it would be
invoked, it would go some steps further in the search, then one could
call such LFUN when the Qt subsystem is idle, i.e., no other enqueued
messages (if a search is in progress). A button on the F&R Widget (or an
ESC keypress) would then allow to stop/cancel the search.
Issues with such an approach would be:
1) where to store the search status information (buffer and DocIterator
where we arrived) ? Guess in the widget, however:
2) it would be absolutely needed a way to return back complex
information from the LFUN dispatch to the caller (the widget);
3) some GUI logics would be needed in order to ensure such "background"
activity is correctly shutdown (e.g., if one closes a buffer, etc...).
One possibility to obtain all of the above would be to get rid of the
LFUN call, and just perform direct calls, or add the DispatchResult
thing I was talking about in my previous message.
T.