Robert Roessler wrote:
Thanks for the explanation - but this does seem a bit cumbersome -
relative to how simple and clean it is advertised to be...
This should be easy to fix - and since the documentation as it stands
would lead one to think it actually works, why not *make* it work? :)
Depends what you mean by making it work -- right now it works reliably
according to its simple rules and anything matching from the anchor
point is found. That said, I'm not opposed to improving it so it might
work better.
Basically, just have SCI_SEARCHANCHOR actually stash *both* ends of the
selection... then, SCI_SEARCHPREV can continue working as it does, but
SCI_SEARCHNEXT could check to see if the "anchor" [still] matches the
selection start (and end?), and if it does, increment it, use selection
end, whatever seems more appropriate.
I think you're focused on the high level find-next operation (what to do
after one match is found). The ability to find the current selection is
needed for the high level find-first operation: if I happen to select
'a' (for example) and then search forward for the first occurrence of
'a', I expect to find the 'a' I already selected. Scintilla could
possibly set a new search anchor after a successful match, but this is
complicated if the user decides to change search directions.
I'm not sure there's a clear answer here, which argues for keeping the
scintilla level functionality simple so that it's easily understood.
Maybe the documentation should include a warning about the find-next
problem.
Cheers,
John
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
