Scrivening Session Emergency Brake Wanted

My novel currently stands at 80,000 words and 65 chapters with all the associated folders and text sheets. If I screw up and hit the top level container, expecting to see cards or outline, but haven’t done the right things to prepare, it starts a scrivening session. I would really!!! like a way to stop that since it freezes up my machine for fifteen or twenty minutes, using 100% of the CPU. Yes, eventually I get control back, but maybe I was hot, throwing down words like crazy, and now I have a forced time-out. Ecch.

Perhaps, before it jumps into a scrivening session of more than, say, 20,000 words, it could ask you if that’s what you really want to do. Or something.

Thanks and Regards,


Common practice in programming would be to have the Scrivening still try to get set up in the background while a popup (and a progress bar) informs you of a long running task and asking if you’d like to stop it. I’d like to see this feature, too.

that’s a great idea. so that if scrivener gets into a state of having to spend a lot of time “thinking”, that there’s some button or button combination that you can press to get scriv to just stop and return control back to user.

or the ability to turn off scrivenings for certain folders because they would take forever to generate the scrivening.

especially for long form stuff, this can be a project saver.

Scrivenings can indeed take a while to put together, especially the first time. The second time it should have more of the data cached in RAM, but the first time it has to go through each file on the hard disk and open and close it—that’s one of the slowest things your computer can do. I think what would be most appropriate is what was suggested above, similar to how automatic backups currently function. If you have a large project file of 500mb or so and get a long progress bar when closing Scrivener, you get a little Abort button as well so you can opt out of the backup. Something like that would probably be easiest to do, or something more integrated, so that if you do anything while it is working it just stops and does what you clicked on. The latter is how the Mac version works, but I’m not sure if that is as appropriate on Windows, maybe a progress bar would be better.

Strong preference for a progress bar.

On the Mac version, scrivenings loading is done in a separate thread, so you can just click on another document in the binder to cancel it. This should be coming to the Windows version, too, although a progress bar and “Abort” button may indeed be a good interim solution.

It’s probably easier just to implement the other thread solution. You have to put it in a separate thread in order to have the progress bar anyways. Either way would be good.

Stopping a thread of work without feedback to the user might be the way the Mac version operates – I wouldn’t know, I haven’t used a Mac for about 12 years – but I am a big fan of “tell me what’s going on.” So that’s why I prefer the progress bar. It says “work is being done” and when I click “Abort”, I specifically did it and, because the progress bar goes away, I also know without a doubt, that the work that was being done has stopped. If the thread is stopped without feedback, how would I know that the Scivenings thread had been stopped?

Well in this particular case, the thread is strictly one of view assembly. So forking the assembly and allowing it to be implicitly canceled by a view request does not, I think, violate any UI expectations. If you click on folder A and get four index cards and then click on folder B and get 10, this is what you expect. If you click on folder A and get 30k words in Scrivenings and then click on folder B and get 20k, this is also expected. When you click on B, the expectation is that the view will switch. So if it just so happens to take 20 seconds to assemble A, should there be any confirmation that one wishes to switch views to B when B is clicked upon? At no other point does the software require confirmation (and direct abort/etc) action to confirm a view switch. I can say from direct experience with the non-confirmation method, that there has never been a single time when I’ve accidentally quit assembly and regretted it, but countless many times where I’ve accidentally clicked on Draft with Scrivenings mode on, and quickly clicked off somewhere else to cancel it or hit the Corkboard key to abort and switch view models to something more efficient. It’s extremely useful to be able to swiftly and intuitively do that.

I think this will become more true as the text engine continues to be optimised. Right now it is a slight investment to build the entire Draft (though honestly I don’t think that is something most people do a lot of, on purpose anyway), so accidentally cancelling it could be a frustration. On the other hand with caching the files into RAM and better text engine performance, that particular aspect will diminish as it has on the Mac.

OK, I (finally) get it. I agree. Clicking on something else in the Binder would set an expectation of canceling the in-progress assembly thread. So I’m back in the no-progress-bar-necessary camp.

Thanks for taking the time to explain, KB and AmberV.

I know this is an old thread. But I’m still not clear. Yes, I can click on another file to stop the accidental Scrivenings but sometime I already have the stalled ball going round and round and eventually have to Force Quit. Is there an “emergency brake” in recent versions? Thanks.

You’re talking about a malfunction of some sort, or perhaps a very intense series of calculations that are never given enough time to finish. Scrivenings itself doesn’t get jammed to the point where there are no resources left to accept user input. Under normal usage, you can be building a large Scrivenings session in the left pane while typing in the right pane, no lag. So I’d contact support about that in particular.