Tuesday, September 11, 2007

IDE Autosave and recovery

I mentioned it in this post, which got me thinking about a new RAD Studio IDE feature; autosave. So what do you think, is some sort of time-based autosave feature something nice to have in a development tool?

Let's spec this thing out. I think you should be able to configure the idle delay, the "modified" state isn't cleared, and the original file isn't overwritten (nor are the __history backups cycled). So if you're working on MyUnit.pas, and it autosaves to a file called MyUnit.pas.autosave. Once you explicitly save the file, the MyUnit.pas.autosave file is deleted. Of course the normal __history backups are cycled and the working file is overwritten. So if certain random sub-atomic particles crash into your memory and cause a meltdown, you at least can recover the autosaves. When the IDE opens a file, it should detect that an orphaned autosave file is out there when you open a file and will ask if you want to recover the autosave by overwriting main working file. You should even be allowed to view the differences before you make that decision. How's that for really designing something on the fly? Anything else I missed? The compare tool should be pluggable/configurable, of course. Maybe allow you to enable this only for only certain files and file types?


  1. I asked for an autosave feature in Delphi years ago (http://qc.codegear.com/wc/qcmain.aspx?d=1178). Unfortunately it looks like this QC entry was closed as part of an automated RAID replication run.

    In any case, my initial request was nowhere near as feature rich as your proposal so I reckon we go with your suggestion instead. :-)

  2. Sounds like a great feature and a good plan for implementing it.

    A few details I'd suggest to include:

    - It should probably make sure to autosave .dfm files, as well as .pas. Probably any .dpr and .dpk files, too. Actually, it'd be cool if it could autosave anything you have open, even if it's not a source file; for example, .txt, .sql.

    - Perhaps it could also autosave the .bdsproj file, if you've changed Project Options but haven't yet done a Save All.

    - Make sure it autosaves *all* modified files you have open in the editor, not just ones that are explicitly part of the project. (Particularly important if you're editing text files and want to autosave them, or if you don't explicitly add all your source files to the project.)

  3. Nice to see this feature finally added to RAD Studio.

    Is this feature added to Delphi 2007/C++Builder 2007 too through the installation of Update 3?

  4. I think this is a great idea. Recovery of an auto-save is definitely a plus with the situation you mentioned above. This feature I know has been around in UNIX (vi) for a number of years and also in Microsoft Office applications and has proven its usefulness over the years. It looks like all the bases are covered (with configurable options, etc), but I will keep thinking on it.

  5. This is a tough call. Here is why.

    Scenario A)

    There are many times when I am typing like a fiend because I am prototyping a design that is very difficult to implement (at least mentally, at the moment, in my head) and so I am surfing various bursts of inspiration by writing code. A lot it quickly, before I test any of it (because it all hangs together after its written). In times like these auto-save would be a god-send. But frankly, I've developed a "Ctrl-S" twitch or tick which is now just automatic in these situations.

    Scenario B)

    However, there are other times when I have a working implementation but I've got in mind some non-trivial enhancement/modification of which the implementation looks more like brain surgery (on my own brain while I'm awake) at first glance. Yeah, OK, so I backed up my code before surgery begins; but, I hate to need to go back to a back-up after coding down a "what if" alley. It messes with my flow.

    So anyway, back to the brain surgery. So once again I'm coding like a fiend to flesh out the ideas as they come to me; but, this time I dare NOT hit "Ctrl-S", because I am not sure at all I want to write this code to my source file until I've run the code a few times. So in this case, an Auto-save would still be handy, just not to my "official" source file. It would be great if I could right-click in the code editor and toggle the "Brain-storming" menu-item. Then a "Brain-storm" sub-directory would appear under my project directory and the auto-saves would go there, while my real "Ctrl-S" saves would still write normally do my source file.


  6. Hi Allen,

    You guys have access to more IDE features requests than you'll ever have resources to do. Autosave is one of those requests.

    Report No: 40093 (RAID: 249076) Status: Open
    Add "Auto-Save" with a timer to autosave files

    Viewing changes on the fly, hmmm that sounds real familiar...




    PS: Why is an email address required? Not that I mind.

  7. Hi Allen,

    How about exposing this to OTA as well?

    Each stage of the decision process of the autosave should call the OTA interface, hence allowing a programmer to override the decision. ;o)

  8. Dennis,

    That's an interesting idea... It sounds kind of like a dynamic on-demand source code "branch." That could be something to include in a source code control interface as well.


  9. Comparison tools, pluggable, configurable... sounds gold plated to me :) Word's one is quite simple, if the file's there it tells you and lets you restore from it, and that's it. No configuration or plugins or anything. I admit diffing would be handy though.

    Have you ever used Firefox 2's feature where it remembers the tabs you had open when it crashes, and reopens with them? It's very useful. Something like that would be a nice addition too.

  10. Allen, what's the QC # for this so I can open it? ;)

  11. I'm currently reviewing a couple of products by AJC Software. Check out AJC Active Backup & AJC Directory Synchronizer. They can give you pretty much what you want with as much (or as little) control as you need. See www.ajcsoft.com for more info.

  12. Allen: Yes, but a very "temporary" cache, as it were.


  13. I'm all for it! Of course, if I close and cancel changes, the autosave should go (an obvious miss in your scenario). Also, I won't autosave until the file is first saved (don't care having backups for quick and dirty experiments)...

  14. I think it is a fantastic idea, as long as it is properly implemented. The IDE is already doing too many slow things on the primary VCL thread:

    At design time:
    1. Tooltip declarations
    2. Help insight
    3. Code insight members list
    4. Parameter lists
    5. Evaluation at run-time

    Every now and again, my IDE just sits there for a minute. Sometimes that’s because I accidentally left the mouse hovering over a variable, sometimes because I had the cheek to type the dot character. Adding autosave to this will make everything maddeningly slow. I think I have a better idea: first move every one of these tasks to its own thread and then implement autosave.

    I already know developers who turn Code Insight off because of the delays, and the same will happen to this if it is not done correctly.

  15. Allen,
    Well.... I already have one which saved my b... more than once, specially in D2005/2006.
    I'm using an old (1999) Delphi (5?) IDE Expert from Ray Lischner that I have tweaked a bit to work in subsequent versions of Delphi.
    The little help explaning how it works:
    "The Auto Save Wizard can save your files at regular (configurable)intervals, helping to ensure that you do not lose information if Delphi or your system were to crash.
    At regular intervals, every modified file is saved into a temporary file, whose name is formed by inserting a tilde (~) at the start of the file name
    When you open a project, if there are any auto-saved files, you are asked if you want to restore the files."
    What I would add is just another possibility of triggering an autosave: whenever I compile (if I don't do a regular "save on compile"). So the choices would be time based, compile based or both.
    I don't really need an autosave sub version system, as I want to master what is saved and how. I just want a crash insurance "a la Word"... Just to restart from where I was...

  16. This has been available as a wizard for years. See here: http://www.dummzeuch.de/delphi/autosave/english.html

  17. re: The too many things done in one thread issue -

    Although you may (obviously) have reasons why some of your IDE services can't happen in their own thread, I think this particularly piece of functionality can be shunted off to its own thread so their should not be any additional performance hit on your current architecture.

  18. I would definitely vote for an Auto Save feature! Having this already in Castalia (and others) I actually don't use it for the following reasons:

    1. Auto Save sometimes pops in just when I'm typing - leading to problem 2

    2. Saving files removes empty event handlers, which is somewhat unexpected with Auto Save

    So I suggest these two features for an Auto Save option:

    - only save when there is no active typing or form designing
    - don't remove empty event handlers

  19. Very nice!! Go codegear!! Go Allen!!

  20. It's a great feature, which is surely missing!
    A detail: "When the IDE opens a file, it should detect that an orphaned autosave file is out there when you open a file".
    I also want this when I do not open the file, but it is being used in my project[group]. My desktop (even when autosaved) does not have contain the autosaved file. I sometimes(!) have multiple instances with the same project group. E.g. one containing the client, the other containing the server. So imagine one IDE crashes, and I close/save the second one, the next time my IDE may open without the autosaved file.
    [Mind-boggling: what if both IDE's have to autosave the same file modified differently...]

  21. Most of the people who save sources have learned this the hard way (IDE and OS stability is not 100%). An autosave would solve that (although its a more or less a dirty fix to ease the pain of unexpected crashes)

    And there's the need to go back in versions (version+date/time), ideal would be something like the standard undo-system (unfortunately that is gone if you restart). An unlimited undo&redo system would solve it (or a more advanced version engine in the __history folder).

    Anywhay, there is a lot of room to improve in that corner and i'm sure we all need such once in a while saving us the ordinary clumbsy file-restore actions.

    Btw: i would appreciate if the contents of the __history folder would somehow be stored in a database (not sure if thats possible).

  22. I would definitely turn this feature on. With an autosave interval of 30 seconds or shorter; I don't want to loose 10 minutes of work when the IDE starts throwing error messages and/or freezes on me again (although this does not happen so often anymore with Delphi 2007 update 3). No advanced feautures are needed; just save the files somewhere, detect them when the IDE is (re)started and autorecover. This is best done on a local drive. Autorecovery information for the IDE should include the project that was being edited when the crash occured.


Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.