@guy038 said:
I’ve just noticed one bug. Luckily, after checking on official versions, that’s NOT due to your version !
I agree with your findings. The trouble seems to come from this section of the source code:
CharacterRange cr = (*_ppEditView)->getSelection();
//The search "zone" is relative to the selection, so search happens 'outside'
int startPosition = cr.cpMax;
int endPosition = docLength;
if (pOptions->_whichDirection == DIR_UP)
{
//When searching upwards, start is the lower part, end the upper, for backwards search
startPosition = cr.cpMax - 1;
endPosition = 0;
}
The line causing the trouble is startPosition = cr.cpMax - 1;
When the caret is here (at the position marked by the vertical bar): abcabcabcabcABC|abcabc and the backwards search for “abc” (without regard to case) is invoked, the -1 in the line above is what causes the search to begin at this position: abcabcabcabcAB|Cabcabc instead of at the correct starting point. Thus, the first match that is found is the last “abc” just before “ABC” (as @guy038 indicated), instead of “ABC”. This supposes that Scintilla’s searchInTarget() function (called later than the above snippet of code) won’t find matches that begin inside the specified range and extend outside the range.
Unfortunately, I don’t see an easy fix to this. If the line is changed to be startPosition = cr.cpMax; then “ABC” is correctly found as the first backward-search match, but repeated presses of the <<Find (my N++ build) or Find Next (real N++ 7.5) button will not move the caret, i.e., it will be stuck on “ABC” forever, instead of finding each preceding “abc” match in turn.
