Vincent van Ravesteijn - TNW wrote:
AFAICS, what is returned by an LFUN may be LFUN dependent.
So we have two options: 1) use the string-encoded return
mechanism, similarly to the current LFUN argument passing
(personally disliked); 2) use a basic DispatchResult class
with proper subclasses which are LFUN dependent.
I don't want to make us lazy by enabling to pass all information you
want back to the sender of the LFUN. I also don't see why it is
necessary, uptil now we only use a bool in some cases to tell whether
the LFUN is processed or not. This might have been misused in some
cases, but a bool has always been enough. Even in your patch, you only
use one boolean.
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. All the other stuff might be
handled in the widget itself. 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
-) or the AcrobatReader-like one Abdel was liking so much, where all
matches would be listed on a dedicated pane where you can click
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.
Besides, if you really need more info, then the LFUN is maybe not the
best way to do it. Then you can probably call the core functions
directly as this will not be of use anyway for server/minibuffer
applications.
This is of course an option.
If it were for me, I would also turn the LFUN argument
passing mechanism from the string-encoded way it is now
to the 2) point described above.
The string-encoding stuff is something related to the
dispatch of LFUNs from the mini-shell, but that may be
achieved (orthogonally) by proper deserialization of LFUN
arguments from their string-encoded version the user is
supposed to type.
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 !
(similarly to kernel-space user-space comms that happens when you open
`top' or gnome-system-manager on Linux).
T.
