Can the auto-save feature be made optional?

I understand the idea behind auto-saves, but it is not always appropriate to have a file saved in the midst of editing. I may not always agree with the Human Interface Guidelines, but it is nice to at least know what the default behavior is likely to be across applications.

Any way that there can be a preference to enable/disable auto-saves and instead allow the usual document-based application behavior?

Thanks!

Fletcher

This concept came up before, here. Basically, if you need a static copy of a document instead of a fluid one, consider playing around with Snapshots. It is kind of like “save” in the midst of the river of editing.

Yeah, the answer to this one is a resounding “no”. The auto-save feature is built in to the core of the new code, and there is no way I’m changing it. Sorry. :slight_smile: Oh, and HIG? What are they? Oh wait, I remember - they’re the things that Apple follow to the letter. :wink:

I guess one of the things that makes the autosave feature tricky (and therefore potentially dangerous) is the fact that not everything can be undone.

I feel that an always on autosave feature should be accompanied by an iron-clad Undo feature. It’s tricky sometimes to remember when something can be undone and when it can’t, and I would be concerned about this leading to trouble (unless I can specify an “auto-snapshot” feature and that just seems like it’s getting totally out of hand.)

And as to whether it can be disabled, I assume that somewhere you have a setting that says how often to poll to check and see whether to autosave? (Clearly it shouldn’t constantly be checking or that would seem to cause a not totally insignificant performance hit, but should have some sort of sleep function.) If so, could this sleep interval be made user-adjustable in the preferences. Then I could set it to something like 1000000 seconds, and you can set it to 2 seconds, or whatever, and both of us should be happy.

Thoughts?

Like I say, this won’t change. :slight_smile:

The auto-save code is the same as the auto-save code in Mori - Jesse Grosjean kindly helped me out on this score. Every time the use hits a key, hits a mouse button etc, a flag is set on the main document to save if necessary. The saving is then delayed until the document has been inactive for a couple of seconds. The project is also saved on quit or close. Thus the only time an auto-save won’t work is if there is a crash (hence there is a “Force save” feature for the over-cautious.

So, no, there can be no setting for this. Without an auto-save feature, you need some visual indication of which documents are not saved, and reminders upon quit etc (such as Scrivener Gold had). I’m decidedly not going down that route again.

Likewise, there will be no auto-snapshot feature. This was discussed elsewhere, and AmberV gave a very good reason why such a feature should not exist (it would balloon the size of your project, for a start).

And as for undo - because I am not using Core Data, undo is tricky, but undo is still fairly decent. Creating or destroying documents destroys the general undo stack, but each text document has an undo manager of its very own. So every time the text editor gets focus after switching documents, no matter whether or not the binder’s undo stack has been destroyed, you can undo and redo everything for that text document that you have done in that session.

So, everything is fairly safe… Deleting documents sends them to the trash folder, and you can undo and redo edits to text indefinitely throughout a session. It is only changes in the binder etc that become undoable depending on certain changes.

The bit on automatic snapshots is here.

What about the ability to customize the autosave delay duration? That would satisfy my needs, it shouldn’t require any

Granted, a file is autosaved before quitting Scrivener, which is not standard behavior, but I can tolerate that.

It would seem to me that somewhere in that autosave code is a variable that says “Wait x seconds” (or the equivalent) before checking “dirty” status. If that variable was managed by user defaults, the plist could be edited by hand if you didn’t want a preference for it.

It seems like this offers a win-win solution - those people who are really bothered by the autosave feature can extend it’s duration enough to effectively disable it, without requiring an overhaul to the code (probably just changing a few hard coded numbers to a variable if a variable doesn’t already exist.)

I’m not sure how useful that would really be… I mean, unless you really want to set it to something obscenely huge, then closing the program would take longer because it would have more to save. As I understand it, the “inactive for x seconds” is designed to not get in your way, and just keep your files safe.

With the full undo stack available right back to the start of the session for each document, I’m not really sure I understand what your objection to auto-save is. I mean, if it wiped out your undo stack when it autosaved coughexcelcough I can see not liking auto-save…

The “full undo stack” doesn’t undo everything. It doesn’t undo file/folder rearranging, for instance. It will undo your actions if you move one file on top of another, but not if you move one file to become a child of another.

Yes, there is a snapshot feature, but again, it doesn’t mange these sorts of changes.

Thus, if you are trying various options of rearranging sections of your document, and it takes you more than some unspecified number of seconds of inactivity while deciding whether you like these changes, too late. You have to manually undo the changes, assuming you can remember exactly how they originally were.

(And before anyone asks, “Well, if you can’t remember the first version, surely it doesn’t matter?” - I doubt that any one here hasn’t had the experience of losing a draft of a paper, and never quite being able to rewrite certain parts as well as they had been written the first time… Which is why people want saves and backups in the first place.)

I can understand the appeal of autosave, but I also believe that it is not the default behavior for the vast majority of Mac OS X applications out there for a reason. I’m not arguing whether autosave as a default behavior is right or wrong, or good or bad. It’s just clearly bad for some users, and good for some others. The problem is that a feature that writes data to your hard drive permanently is often not “just a little bad”, it can potentially be “very bad”, again depending on your method of working.

Scrivener is Keith’s baby, and what he says goes. Fine. I’m not arguing that.

My point is simply that if there is a quick patch to the autosave code (which, assuming that the original Mori autosave code was written in a reasonable fashion, there is) that allows some users to disable it by extending the delay out to a very long time and does NOT interfere with this ability for anyone else, what’s the harm? More than one user/potential customer of Scrivener has requested some ability to disable/modify this feature. I suspect that it might be a turnoff for other potential customers as well. No one is asking that the autosave feature be removed, or that those who like it can no longer use it.

Aye, for project level changes, Snapshots do nothing. It might not be your cup of tea: But what I do right before anything drastic like the actions you are describing, is make a back-up of the project. This is made easy with Cmd-Shift-S, which acts like “Save a Copy as…” does in most other applications. This way, you can name the back-up project something descriptive, without having to close and reload the primary project like “Save as…” makes you do.

I’ve been using that ability periodically anyway. Like you, there have been too many times when I’ve realised two weeks later that really want things the way they were before I made some impulsive massive change. I usually keep a string of back-ups for all of my critical working projects that goes back three months. Hey, a text wranger has to do something with all of that hard drive space they give us! :slight_smile:

I think I see, then…

Because .scriv project files are actually directories, though, to the best of my knowledge file/folder rearranging doesn’t really have any way of leaving something “unsaved” - there are no changes to a file that need to be saved, so you can’t leave it unsaved. Changes inside a file, where the undo stack exists, reflects changes to actual files, but moving a file around doesn’t. I don’t think autosave even factors into that - does it, KB?

I understand fletcher’s concerns, but I must say that in my case at least they are only theoretical. In my case subsequent versions of a document are always better and more complete (or less imperfect and less incomplete) than preceding versions. But I’m an academic writer, not a writer of novels, and this may make a fundamental difference in this respect.

But even if I were a writer of novels, I think I wouldn’t have problems with the present auto save-feature. Every evening, indeed, I make (or rather Synk makes for me) a copy of all the documents that have changed that day; and I keep on an external HD all the various versions of the documents that have changed in the past three months. So in case of changes of mind or disasters of various kinds, it is alsways very simple to return to a preceding version.

Moreover, in case of planned radical interventions (for instance complete restructuring of a novel), it is always possible to make first a complete copy of the present state of the document under another name (“save as …”). So it seems to me that the risks of the present autosave are fairly limited.

I’m increasingly intrigued by the psychology of this thread…

It’s sort of akin to “I like grape jelly. I understand that you prefer strawberry jelly. I realize it’s possible for you to have strawberry jelly, without affecting my ability to have grape jelly, but I would still prefer that you have grape jelly too, because I don’t think that it’s realistic for you to prefer strawberry jelly.”

Definitely the most fun I’ve had with a forum thread for a long time.

Actually, I would say it is more akin to: “There is no strawberry jelly. This particular manufacturer does not make strawberry jelly. Some people like strawberry jelly, sure, but this manufacturer just happens not to make it, as this manufacturer is a dedicated grape-jelly manufacturer.”

Though of course, you really mean “jam”, don’t you? :slight_smile:

:laughing:

I can’t say I ever quite understood this one. Do yanks ever have jam or is it always jelly? Are there regional differences regarding this? Seems to me, I’ve heard “Jam” in the south. Canucks are stuck in the middle as usual: we have both jelly (the clear, gelatinous stuff) and jam (the stuff with actual bits of fruit in it) and brits think Jell-o is jelly. On a related note, is it true that Marmelade was Marie Antoinette’s favourite home remedy (hence “Marie-est-malade”)?
:slight_smile:

E

Actually, whilst I salute Webster on his standardisation of Brit spellings to things such as “color” and “-ize”, which are more inline with their Latin and Greek (respectively) origins, we Brits have the drop on this one.

“Jelly” is from Middle English, from Old French, from Latin, for “gelare”, “freeze” - and the British idea of “jelly” is something that needs plonking in the fridge to set. It’s our transatlantic friends who have this one muddled. :slight_smile:

It’s a good job I’m the mod, or else this thread would have been locked as “off-topic” several posts ago. :slight_smile:

Well, according to the O.E.D., marmalade has comes from the Portuguese, marmelada, and first popped up in 1480 BCE. So I guess that kind of rules out Marie. :slight_smile:

Another one of my mum’s old wives tales bites the dust. Never had the heart to look this up myself. Damn. 1480 BCE, you say. Hmm those ancient portuguese were pretty sophisticated. :smiley:

We quite agree with you up here in the Frozen Wasteland. After all, its “gelée” around our house. I just find that calling Jello “jelly” is somehow weirdly generic.

Back to the topic. I for one like the save/snapsot features just as they are. Thanks for sticking to your guns.

Ack, I meant CE, of course. There wasn’t anything even remotely resembling Portugal in 1480 BCE. Ha.