Neil Hodgson wrote:
Robert Roessler:
Like I said, that was an "offhand" (or "convenience" in working with
the code) remark - the real meat of this is in the previous paragraph,
where I allege that *all* of the "close" matches are working
improperly... it does not look like what we both assumed initially - a
bogus end-case handling problem.
Positions are between characters so the capture range is from the
midpoint of one character to the midpoint of the next.
Try adding this immediately after the lineStart .. lineEnd loop:
if (pt.x < (ll->positions[lineEnd] - subLineStart)) {
return pdoc->MovePositionOutsideChar(lineEnd +
posLineStart, 1);
}
Sigh - as you expect, this works fine. :)
I have trouble wrapping my head around this middle-of-one to
middle-of-next matching... it *seems* bizarre, if not wrong.
However, since I am doing a word_start_position/word_end_position pair
with the returned position, it "just works"... and, I don't know what
I would do differently anyway - the obvious alternative, left-edge to
right-edge of a char clearly wouldn't be able to detect "close" hits.
There is still a *minor* issue with the last char in the buffer
(before it has been "normalized" by being saved and restored)... but
detecting this case and checking for pt.x being within 1.5 * the
average char width from the the beginning of the last char etc was
getting too ugly - maybe this will just be a limitation. ;)
BTW, thanks for the fix, Neil.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
