All apps (at least Cocoa apps) preserve the state of unsaved documents when quitting the app or restarting the computer. Including Script Editor.
With SD I’m always losing those documents, unless I save them before quitting, of course.
Not a serious problem, but an annoyance.
That’s actually not so. Some apps do, some don’t. When auto-saving was first introduced, opinion was (deeply) divided, and there are still a lot of people who don’t care for it. Some of that, I suspect, is because the initial implementation in 10.9 was problematic, and no doubt there are some who just don’t see the need. But there are others with legitimate reservations.
The thing that complicates things about scripts is that they need to be compiled before they can be saved – and that leaves the question of what to do when you quit with a document in a state where it won’t compile. It’s a difficult issue, not least because you can’t make a unilateral decision – it’s no point leaving a .scpt file so that only the originating editor can make sense of it.
Script Editor (which can and does make unilateral decisions) initially handled uncompiled scripts by saving an empty script, and also saving the source in rtf format. The caused a fair amount of confusion, especially as it wasn’t officially documented; people found scripts wouldn’t run, and they couldn’t see why. Nowadays Script Editor first tries to compile, and if that fails, it saves the last compiled version it has, as well as the rtf. It means when you run such a script it might be running different code, but at least something will happen.
But there’s a problem with the rtf, which is where to store it. In applications and .scptd files, it gets saved as an .rtf file. When an editor goes to open a script, it can then look for the .rtf file first; if it’s not found, it knows the script itself is up to date.
In the case of .scpt files, however, the only way to save the rtf is as a resource fork. Again, this mostly works. But resource forks are fragile. You lose them if you put the file on some non-Mac file systems, and you need to strip them if you are codesigning, both of which mean you can easily end up losing your latest version of code.
In Script Debugger’s case, resource forks are automatically stripped when a file is codesigned. That may become an issue if you are codesigning all the time. (Try adding a second .scpt file to an applet and codesigning it in Script Editor; it will be up to you to use a command-line tool to strip all resource forks first, or codesigning will fail. That might be OK in a basic no-frills editor, but it’s not good enough behavior for Script Debugger.) So one convenience might need to be traded for another.
All of which is not to say that it should never happen – like many other things, it’s a matter of weighing up the pros and cons, some of which might not be immediately obvious.
Shane, many thanks for your informative answer (as always!)
Many things I didn’t know.
My description of the issue was not very precise.
My UX issue with the missing Autosave is not about “regular” script documents. I always (try to) save my scripts properly before quitting SD (or SE). The issue is rather with the “Untitled” tabs and windows: When I’m working on any non-trivial script, I always end up with many “Untitled” tabs, where I’m testing isolated code or script variants. Maybe a bad habit.
The annoyance comes when I have to quit SD. Even if the “Untitled” tabs are not holding important code, I still want to have them around when I relaunch SD. But to make them auto-restore I have to go through a dozen of Save dialogs before quitting SD.
That being said, it is clear that an app’s Autosave (like SE) is not limited to “Untitled” tabs, it will always apply to all unsaved documents. And hence your concerns about autosaving .scpt/.scptd files and code signing are fully valid, of course. (Thanks again for sharing all the details.)
In the meantime I helped myself by writing a Keyboard Maestro macro that completely sorts out the problem. (It auto-saves every “Untitled” tab as text script to a temporary location.) So, my issue now is an ex-issue 