Re: Searching for "whole word" in NSString

FROM : John Stiles
DATE : Wed Jan 30 20:37:53 2008

For any interested parties, I've filed a bug on the Find Panel, see
rdar://5715240
And an enhancement request for -rangeOfString:options:, see rdar://5715441
Thanks guys :)

Mike Wright wrote:
> On 29 Jan 2008 12:05:09 -0800, Douglas Davidson <<email_removed>>
> wrote:
>

>> On Jan 29, 2008, at 11:38 AM, John Stiles wrote:
>>

>>> Oh well, off to Radar to file a bug on the Find panel, and I'll
>>> figure out some sort of solution. I can probably use NSCharacterSet
>>> or something and look at the characters on either side of the found
>>> text. I was hoping to avoid that, but it looks like I can't.

>>
>> You should still be able to build on doubleClickAtIndex: to determine
>> word boundaries at either end of your search string and in the found
>> text, and then implement whatever boundary-matching semantics you
>> choose on top of that, without having to use NSCharacterSet or
>> anything of the sort.  Word boundary detection is complicated enough
>> (cf. UAX #29, "Text Boundaries", at
>> http://www.unicode.org/reports/tr29/)
>>  that you really don't want to have to implement it yourself.

>
> So, to use doubleClickAtIndex: to handle phrases like "want to see
> some", you should be able to apply it twice (to the first and last
> characters of the found substring range), combine the returned ranges,
> and see if the combined range matches the range you get for your found
> substring. Say this is "foundRange", would the indexes you use be
> foundRange.location and foundRange.length-1? That should handle even a
> single-character target, shouldn't it?
>
> Unfortunately, testing a simple case in TextEdit, it seems that it can
> treat neither "a:" nor ":a" as "words". Since I sometimes perform
> whole-word (whole-phrase?) searches for such combinations, myself, I'm
> sure some of my customers do, to. (Since it would be off-topic, I
> won't mention how much I hate that Google doesn't respect
> non-alphanumerics in quoted search keys, except to say that the only
> criterion for "correct" behavior in commercial software should be what
> the customer expects--versus what is easy for the programmer.)
>
> (I'm assuming, on the basis of earlier messages, that the Find Panel
> in TextEdit uses doubleClickAtIndex:.)
>
> Regards,
> Mike Wright
> http://www.idata3.com/
> http://www.raccoonbend.com/