Dewlally wrote:Have you checked to see if it's triggered by character count rather than word count?
That was one of my thoughts as well. To the best of my recollection, char count doesn't seem to be the specific trigger either. I wouldn't expect
char count to be the operative difference here, since spell checkers look at words, not letters.
Nor does incidence of error seem to be the cause; if I have, say, 5 "redline" errors in a document, or 50, doesn't make a difference once the WC has passed that hazy line between 8K and 9K words. It either works with total consistency, or it fails with total consistency. Once it starts failing in a document, it does't work there again unless WC is reduced below some arbitrary and hard-to-nail-down threshold.
However, if ~8K words represents a chunk of memory, I could see there coming a point where it reaches 8192 discrete memory units (by whatever measure is being applied), and somehow overflowing the boundaries of a variable set aside to retain the text to be parsed (or a function designed to handle the text).
macOS is moving rapidly toward 64-bit architecture everywhere, and now warns users when we load a 32-bit app, telling us it won't be supported on later OS releases.
I wonder if there's some 32-bit architecture being referenced on the back end with Scrivener's spell checker, and that's ultimately the reason it's having trouble now. At some time in the past, I seem to recall Scrivener made use of Java. If that's still happening, and if it's a 32-bit version of some embedded Java library, and particularly if that library somehow gets involved in the spelling or document-parsing handoff, well, who knows what might happen?