1. From Apple’s NSTextFinder class guide <https://developer.apple.com/reference/appkit/nstextfinder>:
> For example, if a client had the strings “The quick”, “brown fox” , “jumped > over the lazy”, and “dog”, and a NSTextFinder instance requests the string > at index 18, then the client should return "brown fox”. If all the strings > were concatenated together would be the ‘x’ in "fox". Additionally, the > client should return, by-reference through the outRange parameter, the > effective range of the string that is returned. In this example, the range of > “brown fox” is {9, 10}, because, in the imagined concatenation, the substring > starts at index 9 and is 10 characters long. Is there a off-by-one bug with the end of the second string? Or am I really misunderstanding Apple’s counting strategy? The second string seems to be only 9 characters long. And shouldn't index 18 point to the first character of the third string instead? (Well, the 18 is right assuming the length of 10 is actually right. But it isn’t, so it’s not.) 2. Since the first half of my data is in a table view, I guess I’ll supply a list of ranges for the cells’ text and flag that matches shouldn’t straddle boundaries. But should my text for the second half (i.e. the text view) be included in that list (going Make-Range(first-half-length, second-half-length))? Or as a separate string for the text view’s find bar (going Make-Range(0, second-half-length))? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com