Hm, why has this bug not been addressed in more than a year? I’ve just started testing Scrivener but the first thing I realize is that the word count is wrong. Any chance this will be fixed? Or if it is not a bug, what are we doing wrong?
For an accurate wordcount use the project statistics and make sure that project statistics/ options has the exclude comments and annotations button unchecked. Tophee it is not useful screaming something is a bug and should be fixed after a year when clearly it is not. Better to not just play with Scrivener but do the tutorial and find out first.
I know a bit of drama can enliven an otherwise moribund forum, but I’m not sure it’s fair to accuse tophee of “screaming something is a bug” when he qualified his question by asking:
I like to keep my Annotations (notes) inline so I can quickly reference them. This allows me to have notes on individual sentences, asking myself questions, explaining why a particular choice was made over another, that kind of thing. But I also need to hit a word count. Having to go into the menu to get a word count (and wait while it works it out) slows down my flow and gets me out of the head writing space.
As a workaround, I’ve been using the ‘Document Notes’ box. But this doesn’t allow me to make notes on the sentence level, so instead, I have to reference the sentence in the notes. For more complex projects, that I’m still ‘working out’, I’ll often have another document open to keep notes and track between the two.
It’s time-consuming to do these things. But I assume I’m in the minority which is why it hasn’t been addressed.
A bug is something that doesn’t always work the way the programmer expected it to, or some action that under certain circumstances produces a totally unexpected behaviour of the software. Not being able to do what you want with the software is not a bug. The software not behaving the way you want it to is not a bug.
Inline annotations and footnotes have always had to count as part of the running total as you type, because the text editor would run into performance issues under certain circumstances (lots of words and annotations). Project statistics runs a compile in the background, using the current settings, to get a more accurate word count, so if you are stripping out annotations, they won’t increase the word count in that view.
The only way the developer has been able to exclude comments and footnotes from the running word count total is for you to use inspector comments and inspector footnotes. You can convert from one kind to the other and vice-versa, but do keep in mind that if you convert back and forth, you can’t maintain a mix of inline and inspector annotations/comments and footnotes.
If it’s a performance issue, give the user the option of toggling on or off. Some hardware can handle it, some not.
Or just recalculate during the pause, when Scrivener auto-saves (use a visual cue like dimmed text or a bullet next to the number to let the writer know the number isn’t accurate).
I’m also seeing the bug that mikecaputo clearly demonstrated based on photographic evidence. So why is it still not addressed? It has nothing to do with performance. The field “words” at the bottom does not display the same number (shows 9) as “Words” if you expand it (shows 4). That IS a bug, unless someone can convince me that “words” and “Words” are conceptually different things.
Replying to a Stone Age thread, I know, but it looks like this is unchanged since then. I can’t imagine any of today’s hardware can’t keep up with a live word count, so could I add my voice to a request for a live word count (without annotations)?
Firstly, in Scrivener 3 you can very easily get a more accurate count (for some exclusions, not all), by clicking on the stats in the footer bar. You will find options to tune how that counts, as well.
I can’t imagine any of today’s hardware can’t keep up with a live word count, so could I add my voice to a request for a live word count (without annotations)?
Well, for one thing we don’t make software for only those that have the latest, fastest and most expensive computers. A lot of people out there in fact hold back as long as possible, and are using ancient equipment until it breaks, and why not?
But even for newer stuff, I don’t think you are appreciating the kind of lag it would actually take to calculate this, footnotes, filtered documents, excluded styles, struck-through text, and all of the many other things people have implored we exclude from the footer bar and global target bars. It’s not just this one thing!
If you want to see how much lag, between each keystroke, it would take to provide an accurate word count, then open Project ▸ Project Statistics..., set the counting mode to “Accurate” at the bottom, and see how long it takes to refresh.
In even a small, essay sized, project it would make typing on your expensive brand new computer feel like WordPerfect 5 on a i386.
@mikekasky: That IS a bug, unless someone can convince me that “words” and “Words” are conceptually different things.
One method is an estimate, and the other is an accurate count, of the same thing. I’m not sure what you are trying to get at here. You would say the frog changes into something else if you view it through a frosted glass window versus a clear pane of glass? I would think not.
So it’s worth pointing out (again) that this is not a bug, and never has been. It is, at most, a technical limitation. I’m sure we’d all like every count to be accurate always, but there is a reason estimates exist as a concept in this world. Estimates are not a bad thing. Getting rid of estimates would mean getting rid of the footer bar counter, the floating targets window and all of its features, the progress bars in the outliner, the outliner columns, etc. That’s a lot of useful feature set, all thanks to the power of estimation.
Use them for what they are intended for, though. And when you need accuracy, use the Statistics window. That is how it always has been, and probably how it always will be.
That’s my current setting, and there’s no lag that I can see (on a 2020 MacBook Air). But I do take the point that you want it to be usable on older machines.
For me, on an M2 Silicon with a fast SSD, it takes about five seconds to calculate a short 70k word sample project. You must be looking in the bottom left corner to see the progress wheel going.
Oh well, just random variances, I guess. But thanks for the reply – and please check in on it every few years to see when most hardware can keep up, and for me it’s the one really big missing feature.
Yes, and that’s part of the problem I guess, the variability. These features have to scale in a program meant to go to 100k with ease, let alone beyond. There is a very big difference between what we’ll accept as a delay (which might be even faster than we can detect), when clicking on a button, or loading a panel, and what we’ll accept as a reasonable delay while typing. Any lag at all can be disruptive, even 0.5s, and most of our efforts go into eliminating that.
But sure, if hardware makes a massive leap or we find a way to make it easier to trawl 900 RTF files one after the other and filter for formatting found within the text, we’ll obviously consider it.
But it’s probably a taller ask than you’re thinking. The thing with Scrivener is that any truly accurate count is going to require compiling (which is what the Statistics panel actually does in the background), and that automatically implies a lot of disk usage and miles of code. That means that even if future system could do it in “real time”, it would still mean Scrivener consuming a large chunk of the system’s resources, constantly, which also means poor energy use and battery times. Keep Activity Monitor / Task Manager open while compiling, to see what I mean. A larger project can consume gigabytes of RAM and peg the CPU at 100% across multiple cores, sometimes for minutes on end. That’s what Scrivener would always look like.
I’ve just started testing Scrivener but the first thing I realize is that the word count is wrong. Any chance this will be fixed? Or if it is not a bug, what are we doing wrong? 
