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.

Reply via email to