John Ehresman wrote:
Robert Roessler wrote:
I must be missing how these are supposed to work together, but they
seem to be broken (as a pair).
SCI_SEARCHANCHOR came from John Ehresman and Stephan Diebel for
their Wing IDE where they needed a version of search that could be
recorded into macros. I've never used it myself.
OK... but shouldn't we get an official pronouncement (like from you or
the authors) that it does or doesn't work as documented, and then
follow up on that accordingly? By fixing it if required (although the
problem seems to me like it could be a design flaw), or documenting
the limitation if it does turn out to be a problem?
If the text at the search anchor matches the search text, it is found by
search-next so that the first such search finds it. To search for the
next occurrence after previously performing a search, advance the
character one by using char-right, reset the anchor with search-anchor,
and then search. This requires a bit of work by the code that
interfaces with scintilla, but has the advantage of being simple to
understand.
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? :)
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.
It looks on casual inspection like this can be made to work... of
course, I already switched over to find_text a couple of days ago. ;)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
