>the next step in that patch would be to remove passing of >the BufferView object to lyxfind.cpp (and corresponding >putSelectionAt() and replace functionality), but limit it >to exclusively returning the match (DocIterator and length, >a bool does not suffice), or making some progress towards >finding the next match.
This has nothing to do with the LFUN mechanism. You can freely choose to return something else from findAdv and then put the selection in BufferView itself. >All the other stuff might be handled in the widget itself. That's not correct. If I enter a command in the minibuffer to find the next match, we shouldn't be dependent on some code in a widget in the frontend to put the selection at the correct position. >This change would open up the way to implement a different >FindAndReplace behaviour, for example: > -) the one suggested in some tickets to find all (visible) >occurrences and highlight them someway You can make an LFUN that does this without explicitly passing all the information back. > -) or the AcrobatReader-like one Abdel was liking so much, >where all matches would be listed on a dedicated pane where >you can click In this case you can access the core functions directly, as it will be useless anyway to have an LFUN that returns all this information. >And, I would propose to have the DispatchResult used only >when necessary, i.e., all current LFUNs are happy with a >boolean, so the base class would just be ok for all of them. I would propose world peace ;-). >> This is completely equivalent right ? Whether we pass a parameter >> object directly or whether we pass the serialized object. >> >yes of couse. I keep wonderiing why software components communicate >among each other by means of formatting/parsing human-readable strings! > I keep wondering about your president, and still he is there ;-). Anyway, without joking, you didn't convince me yet that these changes are necessary. Vincent
