[Ambit]

Hello,

I'm still learning to use Objective-C, but in my experiments was wondering how software like Nisus, Ulysses and various others achieve the live word and character counts that they show as the user types. Does anybody have any idea of the best way to implement this? I thought it would be quite straightforward seeing as it is used so much, but after googling for quite some time I haven't found any really obvious answer.

Obviously all I really need is a way of counting the words in a text view that is efficient enough that it can be run in the background constantly without slowing anything down. At first I thought it would be as doing something as simple as:

NSSpellChecker *NSSpell = [NSSpellChecker sharedSpellChecker];
NSString *myStr = [NSString stringWithString: @"Hello, world! One, two, three..."];

// (In a real app myStr would be replaced with [myTextView string]...

int wordCount = [NSSpell countWordsInString: myStr language: @""];

However, this just returns zero all the time. I read somewhere that this is a bug caused by the fact that the word count doesn't work unless the string is being spell checked...

Anyway, I then found some Objective-C algorithms for word counting in this Cocoa Builder thread:

http://www.cocoabuilder.com/archive/...04/6/10/109398

I'm not sure how suitable any would be for a word processor-based app, though, as counting based on spaces only doesn't account for new lines etc... I'm sure they could be modified, but because of my newbie-ness to Cocoa, I'm just not sure how processor-hungry they would be for a live count (I don't want the user to find that typing is painfully slow with live word count turned on...).

If anybody has tackled a similar problem or has any advice on the best way of approaching this, I would be really grateful.

Many thanks,
KB

[endian]

you could do [[[textView textStorage] words] count]. or see [http://www.cocoadev.com/index.pl?NSStringCategory]

[Chuckit]

Probably the fastest method for a live word-count — and the one that MS Word seems to use — would be one that tracks the changes made within a certain "edit" (however you want to define this) and adds them to the running document tally. That way you don't continuously have to parse through the document to count words; you only need a subsection that is usually pretty small. Counting words in the entire document would degrade pretty badly (I don't see how you could get it faster than O(N)) in a large document, whereas breaking it down like this should give you pretty much constant time.

As for the actual word-counting algorithm, that depends on your needs. You could simply count all the clusters of printing characters surrounded by non-printing characters. But maybe you want to count hyphenated words as two or something. And this method of word-counting wouldn't extend, for example, to Japanese or Chinese. You need to come up with specific requirements for your algorithm — then writing it shouldn't be too hard.

I can't really imagine what use a beginner would have for live word-counting, though. Making a word processor is well beyond newbie level.

[Ambit]

Many thanks for the replies so far, much appreciated.

>>"I can't really imagine what use a beginner would have for live word-counting, though. Making a word processor is well beyond newbie level."

Chuckit - thanks for the tips. Just for the record, I'm not trying to write a full-blown word processor. For a start there is no need as there are too many good ones already (Mellel and Nisus, for instance), but I'm also not so naive as to think that I could write an app like Word upon putting down Kochan and Hillegass. That said, I am looking to write a program that has some basic word processing features. Nearly all of what I need is already done by NSTextView - I have no need for tables, footnotes, etc - but as it is for drafting documents, I do want to include a word count. When I said I'm a newbie, I meant to Objective-C and Cocoa - I have been using procedural C for a few years (self-taught), have created (before moving to a Mac, of course) a few small apps with the WinAPI (non-MFC), ventured (not very far at all) into C++, and done a fair bit with a couple of scripting languages and also VB (mainly in Access database creation, though). In other words, I have always been a bit of a dabbler and hack with lots of bad habits and am now trying to do things "right"; there is a particular project that I am aiming towards, which is why I've decided to throw myself into Objective-C and Cocoa. I don't expect to be able to achieve what I want overnight, but while I learn I am just throwing some questions out there to try to get a good idea of how far I have to go and whether my aims are realistic. I find your words quite discouraging, but appreciate the injection of realism.

Back to the word count: as I understand it from what I've seen online (I don't have Word on my Mac), even Word slows down quite significantly using live word count... I'm not a mathematician, so I don't understand what "O(N)" means - I looked it up and believe it to be the notation for "linear" in Big O notation, so do you just mean that it can't be faster than parsing through the string in a linear fashion (character-by-character)?

endian - thanks for the link, that looks really useful.

Many thanks again for the pointers, and any other hints always appreciated.
KB

[Chuckit]

Sorry I came across a little harsh. There are a lot of people who hear that building applications with Cocoa is easy, and then come on here and go, "Okay, I don't know anything about programming besides I made a Web page once, so somebody tell me how to make a kickass [MMORPG/Word killer/Photoshop replacement] in Cocoa language. I'm gonna be RICH!" So when somebody throws out something kind of ambitious-sounding for a "first project," I want to make sure they understand what they're getting themselves into. You sound like you've got a pretty good groundwork.

Anyway, O(N) is "Big-O" notation for linear time. It means that the time an algorithm takes will increase linearly with the amount of data put in. Twice as much data takes twice as long. I was saying that if algorithm speed is a problem, one way to get around it is to find a way to break the text into more manageable chunks. Even a pretty inefficient algorithm shouldn't have too much trouble with the amount of text entered in a normal edit.

I wasn't really talking about a specific way to count words, but a way to keep the resource usage for a live word-count as low as possible — only count the words you don't already know about.

[Ambit]

Thanks again. I completely understand, as I've seen many similar posts on various boards, and my first post was a little ambiguous. My ambitions for my first project are hopefully quite modest - a table view that lists .txt and .rtf files in a specific folder on the hard drive, which can be used to open or edit them in an attached text view (with a word count). I can then build this into something more advanced as I progress. But before even trying my hand at this app, I'm putting in the effort to learn Cocoa properly with the books I've been recommended (Kochan and Hillegass for the groundwork, Anguish for a big solid reference). So I shouldn't really be asking about word count yet, I was just experimenting as I learn, trying to gauge whether it was something I could do simply in Foundation or something I would need to put a lot of work into (and it seems it's a bit of both - easy to get a basic word count, but it will take some work to ensure it's fast and able to cope with different languages).

Thanks for the explanation of O(n) - if I understand correctly, in the case of a word count it can be translated as: (time it takes to check if a character marks the beginning or ending of a word)*(number of characters). I think I'll experiment with the code snippets I have and see what works fastest, but chopping this down into "edit blocks" rather than counting everything sounds like a really good idea.

Anyway, thanks again for taking the time to reply, much appreciated.
KB