When a text file is open and modified in the Editor, the system (via
EditorSupport?) should (at least as an option) periodically create autosave
files, a la Emacs. It is very frustrating to lose edits to a file simply because
a beta VM crashed (e.g.).
Where the files should be stored?
Should be in the same directory as the main file. E.g. Emacs uses .#Foo.java for
Foo.java. When the file is saved, the autosave file is deleted. If the file is
opened and an autosave file exists, you are prompted whether you want to restore
from the autosave; if you say yes, the buffer is loaded from the autosave file,
and is left modified.
Still possible I guess, close as WONTFIX if desired.
Not closing, it's a good idea.
reassigne to David K., new owner of editor
Don't forget about Runtime.addShutdownHook, which would permit NB to
create autosaves of files if the VM is shut down impolitely - e.g.
Ctrl-C on console, log out of X session, shutdown on low battery
power, etc. This could avoid a lot of situations that would currently
lead to data loss.
*** Issue 26476 has been marked as a duplicate of this issue. ***
Auto save will be fine.
But it will be also nice to keep the files in memory.
If you delete opened files, while working (i tried this ;-( ), from
konsole (etc.) then normally editors keep them in memory and you
only have to save them on disc again.
To summarize desired features:
1. While editor is open and modifications are made, should try to create
autosave files at regular intervals.
1a. In same dir as real file if that is possible, else in /tmp or something if
that dir is not writable.
1b. File naming convention a la Emacs; most software (e.g. Ant) automatically
knows to exclude such filenames.
1c. Ideally, temporarily disable autosave when buffer shrinks dramatically, to
prevent loss of much text at once, again a la Emacs.
2. Regular IDE shutdown already prompts to save open files. There should also be
a VM exit hook to write out any still-modified buffers to autosave files, in
case there is a normal (non-fatal) VM exit but that save dialog fails somehow.
E.g. in case an OOME is caught and the IDE has to be shut down with little extra
3. Upon opening a file with an extant autosave, should prompt to load the
autosave (leaving buffer modified), or open unmodified file (deleting old
autosave file in either case).
4. If a file is modified in the editor and it is deleted on disk, should make an
autosave before closing the editor window so changes are not lost for good.
increased priority to P2
A nice, additional feature would be to extend the auto saving by doing like
Intellij; when the IDE window loses focus (developer has switched to another
window) all files are saved.
I think this is pretty important. Data loss due to the lack of this feature is
not really acceptable.
See Michel's new module.
Reassigning to new module owner mslama.
*** Issue 60832 has been marked as a duplicate of this issue. ***
*** Issue 145741 has been marked as a duplicate of this issue. ***
I will implement issue #145741 for plugin http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=2404
So, will be possible save file time after time or every time user get out focus from unsaved file.
I am thinking to publish it at contrib repository, do you see any problem about it? I hope to be possible to rewrite the
tor module and create property to user define if want or not use these features, since it can be painful for people who
use CoS feature.
To keep this at nb repository I need to change license to CDDL or GPL, pr LGPL is fine for this?
To be in the NB source repo it should be CDDL+GPL and I believe you will need to have signed a Contributor Agreement:
I pushed my module to main/contrib. I am working at a refactoring, so the module is still buggy. The changeset is
Comments are welcome.
*** Bug 201650 has been marked as a duplicate of this bug. ***
*** Bug 202284 has been marked as a duplicate of this bug. ***
An alternative would be for localhistory to track unsaved changes until the file is saved.
(In reply to comment #21)
> An alternative would be for localhistory to track unsaved changes until the
> file is saved.
we could do that
That's an excellent idea. It's kinda like writing a filesystem journal for uncommitted data. When the user restarts the IDE, it just loads the saved file and then rolls forward from the journal. As long as the journal is date-stamped properly, you'll avoid the race condition where the file got saved and then the IDE crashed before the journal could be purged. Then there's the really bad situation where the IDE crashes in the middle of the save and trashes the file, which may be an argument for writing snapshots instead of or in addition to a journal. Something to think about.
Just a comment regarding the user experience when a crash happens. In ideal case, if a user restarts the IDE after the crash, it reopens all files and restores them into "unsaved" state containing all edits done before the crash.
How close to that we can get with the local history solution?
(In reply to comment #24)
> Just a comment regarding the user experience when a crash happens. In ideal
> case, if a user restarts the IDE after the crash, it reopens all files and
> restores them into "unsaved" state containing all edits done before the crash.
> How close to that we can get with the local history solution?
hm, had to figure out how to distinguish if a file wasn't saved because of a malfunction or because the user deliberately discarded the changes ...
the question is if the LH should be:
1.) a kind of a workaround and we implement it as a separate enhancement of local history which would make sense by itself - the history of a file will also contain periodically stored unsaved state(s) and the user would be eventually able to pick/recover from them in the history view.
2.) the module completely taking over the responsibility for this feature (see comment #9) including also the smooth user friendly recovery etc.
speaking for LH i would say its 1.)
this is a useful feature, filled a long time ago. is there any technical reason this haven't been done yet by the owning team anyway?
Contrary to some of the other comments on this report I believe we should take a different route when implementing an auto-save feature in NB.
My proposal is more akin to what e.g. MS Office does, i.e. periodically saving a copy of the file in *another location*. Unlike MS Office I believe that 'other location' should be the user dir, not the file's own location. This will keep the auto-save file out of any VCS.
The existing Plugin by Michel Graciano (it in HG in main/contrib/autosave) does its job by executing the save-all action at regular intervals, i.e. it is similar to manually pressing the Save-All icon from the IDE, pressing Ctrl-Shift-S, etc.
While this approach certainly gets the job done it cannot distinguish between the cases where the user actively decides to save a file or when the auto-save feature has done it for him. In contrast the 'MS Office' style auto-save does just that. I often open a file in a IDE, change something, but do not necessarily want that change saved .. at least I wouldn't like it happening behind my back.
What I propose here is more complex to implement in the sense I doubt it can be done by 'an outsider' in a plugin. The benefits are huge though: (1) It will be easy to implement crash recovery similar to what MS Office does on startup and people will be familiar with it. (2) We will not pollute the source tree with auto-save files. (3) Auto-save files will be local to the user and local to the workstation (which is the way it SHOULD be).
Apart from the fact that I'm not sure my proposal can be done in a plugin I believe it is a lot cleaner, easier to understand, stays out of the source tree and generally avoids some of the issues discussed above.