While I've come across several ways to implement/enable autosave (see: Is there a notebook autosave frequency configuration?, Saving my code before cell evaluations: Insurance against front end hanging, How can I set up a versioning system within a notebook?), I've never found a reason why it isn't enabled by default.

It seems incredibly useful to me - surely there must be some good reason why Wolfram chose to leave it unconfigured!

Why isn't autosave enabled by default?

  • 5
    $\begingroup$ Why should it be enabled by default? A feature that's incredibly useful to one person does not mean it's incredibly useful to everyone. It's bad enough that there is no undo in Mathematica. No undo + autosave is just nightmare^nightmare. The simple solution is to not let monkeys sit at your desk and make you lose your work. Even simpler is to save your work regularly. $\endgroup$
    – rm -rf
    Jun 10, 2013 at 6:01
  • 6
    $\begingroup$ Yes, auto save removes the ability to choose the "point of save" from the user and places it in the software's hands. I'm not sure if you're actually aware that there is no undo in Mathematica. Imagine now if the monkey had instead done Ctrl-A and deleted all contents... Auto save + no undo would've meant you've lost your entire notebook, not just the unsaved changes. You could've done this accidentally as well (it certainly has happened to me). All modern software that autosave or "soft save", support multiple (often unlimited) undo. $\endgroup$
    – rm -rf
    Jun 10, 2013 at 6:30
  • 2
    $\begingroup$ IMO, this is not a good question to pose here. This is something to take up with Wolfram if it is important to you. $\endgroup$
    – m_goldberg
    Jun 10, 2013 at 6:30
  • 2
    $\begingroup$ btw, I've been bitten badly a few times (when starting out with Mathematica) by the lack of undo and accidental overwriting + saving and not being able to revert my edits. Nowadays, any notebook that's worth keeping for more than 1 day, I place it under version control (git). I don't commit every few minutes, but say, something like after 5-6 hrs or after the day's work (or sooner, if I've done something substantial). This way, the worst that could happen is I lose 5-6 hrs of work and nothing more. $\endgroup$
    – rm -rf
    Jun 10, 2013 at 7:10
  • 5
    $\begingroup$ Not only that, but also, saving a large notebook over a network can take a considerable amount of time, during which the front end is essentially frozen. It would be quite annoying if this would happen frequently when one is trying to work. $\endgroup$ Jun 10, 2013 at 8:39

2 Answers 2


At Mr. Wizard's urging, I'll post my reasoning for why this is not enabled by default (and should never be, for Mathematica):

  • Mathematica does not have more than 1 undo, period. This is perhaps the single most requested feature since version 1.0. Even that single undo is not well defined — one might expect (from familiarity with any other software out there), that a CtrlZ would undo the last input character/word, but no, Mathematica treats it (approximately) as "Undo everything that was changed in this cell since the last evaluation and last recorded cursor position". This could be anything from 1 character to 10 lines of code. And the best part — there is no redo!

  • More importantly, from a design PoV, enabling auto save by default removes the ability to choose the "point of save" from the user and places it in the software's hands, which can often be disastrous. For example, imagine if you were playing an FPS and the game "decided" to auto save just as you got fragged, instead of at that sweet spot you would've chosen, next to all the health and armor...

    Combined with the lack of any ability to undo changes, this effectively means that anything you type in Mathematica would be "permanent". While more and more applications (such as Apple's and MS' office suites, Adobe's Creative Suite, etc) are indeed moving towards the "don't worry about saving" approach (since your data is often stored on the cloud, thus necessitating a save or at least, a "soft save"), note that almost all of them support multiple levels of undo.

To avoid running into such problems, you might want to get into a few (good) habits:

  • Remember to save your work often. Today it was your friend, but tomorrow it could've been an unexpected power outage and no battery/backup power. You never know when and how you could lose your hard work.

  • Make it a point to place your notebooks under version control if you think it will be useful for more than one day. Although I don't normally recommend placing notebooks under version control, as long as you're using it as a "poor man's backup", it should be fine.

  • Try placing your code in packages (which are plain text files) and use a decent text editor to make your changes. This does take a bit of getting used to, but will be helpful in the long run. I personally use vim to do all my editing work, and it gives me an entire undo tree! In other words, I can go back in history and follow a different path of development and cherry pick changes from a previous branch, etc. Combined with a ridiculously large history limit, I can almost always go back to the first day's edit (not that I need to).

    Just to illustrate, here's a few lines from the vim undo tree for one of my files. In theory, I could go back in time 4 weeks ago and redo a change from one of those undos

    Most decent editors have similar features, and so unless you need the interactive features of the notebook or the front end, I'd urge you to avoid using it if you can afford to.

  • $\begingroup$ Just FYI, if one really needs a "poorer" man's backup, one could also try saving notebook files in Dropbox or other similar services which keeps a simple version history. For small files (say <25MB) it simply works without difficulty for me. $\endgroup$
    – Leo Fang
    Jun 10, 2013 at 15:47
  • $\begingroup$ Now this is something that I can print in color 36 pt. font, on a nice sheet of 68 pound paper, and take up with Wolfram. Well done. $\endgroup$ Jun 10, 2013 at 15:59

Try running this for autosaving your notebook at fixed periods. At least this way you will only lose a few minutes of work if you get another crash.

save=DynamicModule[{autosaveTime = 1, nb = EvaluationNotebook[]},
   "Autosave every", Spacer[5],
     InputField[Dynamic[autosaveTime], Number, FieldSize -> 1.5], 
         Module[{autosaveTimex = autosaveTime}, autosaveTimex++; 
          autosaveTime = Max[1, autosaveTimex]], 
         Appearance -> "Palette", ContentPadding -> False, 
         FrameMargins -> 1, ImageMargins -> 0, ImageSize -> 20]},
         Module[{autosaveTimex = autosaveTime}, autosaveTimex--; 
          autosaveTime = Max[1, autosaveTimex]], 
         Appearance -> "Palette", ContentPadding -> False, 
         FrameMargins -> 1, ImageMargins -> 0, ImageSize -> 20]}
      Spacings -> {0, 0}], Spacer[3], "Min"}],
    Button["Start Autosave",
     autosave = CreateScheduledTask[{
        }, autosaveTime*60];

    Button["Stop Autosave",

You can also add it as a docked cell

 DockedCells -> 
  Cell[BoxData[ToBoxes@save], Background -> Orange, CellMargins -> 0, 
   ShowStringCharacters -> False]]

enter image description here

  • $\begingroup$ it works!!! everyone's else's autosave at timed intervals either only partially worked or didn't work at all. i have a question about ShowStringCharacters -> False inside DockedCells. What does that do and why is it necessary? $\endgroup$ Oct 8, 2020 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.