Hi,
consider
WORD_FIND
WORD_FIND_FORWARD
WORD_FIND_BACKWARD
They have slightly different behaviour, arguments, etc... e.g.:
-) FIND triggers the simple find dialog if without args
-) FIND uses a cache of the dialog params, whilst FIND_FWD/BWD use an
independently cached searched string
-) FIND wants the whole data/options from the simple find dialog as args,
whilst FIND_FWD/BWD want just a simple search string as arg.
The overall picture here sounds like a dirty/messy implementation with code
replication (in BufferView.cpp), and confusing behaviour for the user, e.g., if
I use C-F and I find a string, then I use word-find-fwd, nothing happens, but
I'd expect to keep searching fwd (or bwd, if I use the other lfun).
I'm attempting a refactoring of these, but some feedback from the list would be
useful in terms of:
a) do we really need all of these LFUNs just to support simple search ?
b) when using find-fwd and find-bwd, do we want to re-use the find options as
set in the simple find dialog ? My guess is YES.
c) does word-find w/out args really need to trigger the dialog ? The current
keyboard binding uses simply
\bind "C-f" "dialog-show findreplace"
so I would suppress such a behavior if unneeded.
d) if we allow for searching the currently selected text, as requested by some
users/tickets, I guess we should look at the selection when no args are
provided to the lfuns. Then, what priority do we give to:
i) LFUN arguments
ii) selected text
iii) cached search string and/or options
and again, with what options to search, when searching the selected text?
Note that, after each successful search, the matching text gets selected.
Comments welcome, thanks.
Tommaso
