Comment 1 Nick Edgar 2003-03-07 10:00:28 EST

There are no plans for the UI team to work on this defect until higher priority 
items are addressed. If you would like to work on this defect, please let us 
know on the platform-ui-dev mailing list.

Comment 2 Matthew Booth 2003-07-18 14:23:59 EDT

In an effort to up the priority of this defect:

I'm a long time vim user, but decided to give Eclipse a go for the first time
today. It crashed and I lost about 2 hours work because nothing is ever backed
up. Although the IDE seems very good, I don't think it improved my productivity
today by the 2 hours it lost.

This seems far more fundamental a problem than any conceivable whizz-bang feature.

Comment 3 Ralf Hauser 2003-11-21 03:08:19 EST

my eclipse 2.1.1. also crashes about 1-2 times a day. I save my work frequently,
but still, it is a nuisance to do so if the machine could do it and even if the
loss is not two hours, it is still a big nuisance to do a "mental roll-back" of
the kind "where was I 15 minutes ago?"

Pavel, pls up the priority of this!!

Comment 4 John Didion 2005-08-25 20:53:25 EDT

Please, please, PLEASE copy IntelliJ on this one. With IntelliJ, you never have
to think about saving your work. I have been using IntelliJ for years and can
count on one hand the number of times I've lost any work from crashes (which are
quite frequent since I use EAP builds), and when I have lost work it has never
been more than a few dozen lines of code.

Here's how it works: Everytime you switch from one tab to another, or anytime
IntelliJ loses focus to another application, the file in the editor tab losing
focus is saved.

It would actually be very cool if you combined this behavior with a time-based
auto-save. The active tab would get saved every n-minutes, or whenever you
switch to another tab, whichever comes first.

Comment 5 Nikals Hallqvist 2005-09-13 06:17:38 EDT

Clearly I was very surprised when my Eclipse session died today at noon, and
all my work since morning was lost.  I have been an emacs user since the
mid-eighties and autosaving has been part of emacs all of that time.  I thought
this was one of the first features added if writing an editor.  Manual saves are
not quite the same, since manual saving is a form of snapshotting of known good
state.  Autosave files should be separate files, and if found on open of a file,
there should be a dialog if it is to be considered or ignored.  Ideally, a
file comparison editor should be brought up so you can see the diffs.  In emacs,
only the timestamp and size differences are shown to the user.

I vote for upping the priority of this feature request way high, since this is
actually a safety feature.  it should still be lower than security fixes of
course, but actually higher than reliability fixes, and way higher than
non-safety capability additions.  Just my $.02...

Comment 6 Paolo 2005-09-13 07:51:50 EDT

According to some user inputs which also think this is a higher priority bug 
for an editor, I tried as the submitter to raise the priority. Unfortunately 
bugzilla doesn't like that...

Comment 7 Foxyshadis 2005-11-07 05:27:25 EST

Pretty amazed that it's up past version 3 now still with no autosave in sight. I
don't know why this is so low priority when almost every other text editor and
IDE in the world has it.

Comment 8 Dani Megert 2005-12-07 02:24:38 EST

*** Bug 118145 has been marked as a duplicate of this bug. ***

Comment 9 Glenn Fowler 2006-01-30 19:23:28 EST

Another vote for this one - although it doesn't happen, when crashes occur it is a right pita to work out exactly what was lost.

If the 'save on switch focus' method is implemented, there is still a need for a time based mechanism when a single file is getting all the user's attention.

I agree that the autosaves should be separate from the deliberate saves (possibly with the option to show/hide autosaves when looking at the local history, but at least mark them as autos)

Comment 10 Dani Megert 2006-02-08 10:24:13 EST

*** Bug 126897 has been marked as a duplicate of this bug. ***

Comment 11 Jeff Myers 2006-02-17 14:01:41 EST

If I had to venture a guess as to why this feature hasn't been implemented yet is it'd be quite tricky to do with Auto Build enabled - i.e. you wouldn't want your whole workspace to start sprouting compilation errors because you're in the middle of restructuring a key class.  Perhaps incremental saves could be put into a temporary location in the .metadata, or make diffs like the local history feature - but not actually saved on the actual project file.  This auto-save file would be blown away in a real save or a close of the editor.  After a crash, if the editor discovers the auto-save file, the user could be prompted whether they'd want to load the auto-saved version or the real one on disk.

Comment 12 Vijay Aravamudhan 2006-02-22 20:36:53 EST

i have a good mind to start working on this as a separate plugin. Any volunteers to help? Or any hints on where to start?
These are some thoughts that I have currently:
1) Look at implementors of 'org.eclipse.ui.IStartup' to attach a listener to the workbench for focusLost events to save the active editor.
2) Use EditorManager.getDirtyEditors() to save dirty editors on a timed basis.
3) Look at 'org.eclipse.core.runtime.jobs.Job' to actually do the save step in the UI thread (or out of it? ie either use Display.asyncExec or Display.syncExec)

Obviously: this will not handle saving when you switch editors, nor will it bypass the builders if auto build is turned on. But at least it will save.

Comment 13 Vijay Aravamudhan 2006-02-23 10:42:16 EST

Created attachment 35235 [details]
first cut of plugin to save dirty editors when workbench loses focus

A first cut at a plugin to save dirty editors. Currently the save operation will be triggered only when the workbench loses focus. Look at the 'Changes.txt' and 'Todo.txt' files included. I will also host it on sf.net for cvs and other infrastructure requirements.
If you find it useful, drop me an email for new features :)

Comment 14 Douglas Pollock 2006-02-23 10:52:46 EST

Jeff, you're pretty much right about the auto-save feature.  It's not as simple as the problem first looks.

I think you'll find the naive auto-save with auto-build very frustrating -- especially for large workspaces.  There are also issues with the local history.  If the saves are too frequent, the local history becomes hard to use.

I think a good first attempt would involve saving the files to the metadata area.  Perhaps one back-up per file, flushed when the file is properly saved.  The triggers for back-up could be time or changing the active editor.

Vijay: Thanks for your contribution.  I could see the plug-in existing as a dependency for "org.eclipse.ui.ide", and adding the functionality of time-based saves.  The plug-in leaks a window listener on shutdown.  Also, you might want consider some of the things I've mentioned above.  It would be nice to see future revisions of the plug-in contributed back to this bug report.

Comment 15 Vijay Aravamudhan 2006-02-23 15:13:23 EST

Created attachment 35259 [details]
version 2: now works with eclipse 3.1

same functionality as before - but now also works with eclipse 3.1
I have also added more comments into the Todo file based on what Douglas Pollock suggested (thanks Doug!)

Comment 16 Vijay Aravamudhan 2006-02-24 17:50:51 EST

The latest code is hosted here: http://sourceforge.net/projects/savedirtyeditor

I will try to get a 1.0 release out by this weekend

Comment 17 Vijay Aravamudhan 2006-02-25 16:17:26 EST

i have not been able to release a 1.0 version - but the latest code has been checked into the version control system in sf.net, and there's a project page: http://sourceforge.net/projects/savedirtyeditor/

The only thing missing is a preference page: so the save-time-interval has been hard-coded as 5 mins. I would really appreciate it if anyone can test this and report bugs/RFEs.
The code has been released under EPL v1 and has been bundled into the zip archive. But I would appreciate it if any changes/fixes are sent back to me so that it can benefit the whole community. Enjoy.

Comment 18 Vijay Aravamudhan 2006-02-25 16:37:36 EST

i forgot to mention - there IS a 0.0.3 release and the changes.txt file has the release notes.

Comment 19 Vijay Aravamudhan 2006-03-01 01:39:10 EST

Release 1.0.0 is here:
http://sourceforge.net/projects/savedirtyeditor/

This includes all functionality that were mentioned in previous comments - except saving into the metadata area. I could not find out how to do this and at the same time work with IFile instances (for reconciliation). I would appreciate feedback from the reporter if this plugin is acceptable.

Comment 20 Douglas Pollock 2006-03-01 09:34:10 EST

(In reply to comment #19)
> Release 1.0.0 is here:
> http://sourceforge.net/projects/savedirtyeditor/

I know this is going to sound weird, but can you attach the plug-in to this bug?  It's a legal thing.  (http://www.eclipse.org/legal/termsofuse.php)

Comment 21 Vijay Aravamudhan 2006-03-01 10:29:06 EST

Created attachment 35542 [details]
v1.0.0

hmm - not sure what the legal point is coz I have released it under EPL and the distro comes with the sources bundled inside as a zip file. Anyways - here it is. Again, please send feedback if you do find anything that needs correction.

Comment 22 Vijay Aravamudhan 2006-03-01 14:59:07 EST

Created attachment 35558 [details]
some bug fixes/performance enhancements with job scheduling

found a bug when using multiple monitors and fixed it.
now intelligently schedule jobs when part is activated/deactivated.
also remove the snapshot when the editor is saved so that reconciliation is not triggered falsely.

Comment 23 Douglas Pollock 2006-03-01 17:01:16 EST

Next time you attach the plug-in to this bug, could you export the plug-in using "Export > Archive File"?  This just means that others can more easily import it as a plug-in project....

I've started looking at this, but it's a lot to digest all at once.  My first concerns are the use of the internal CompareAction (which we can probably work around) and the problem of how to save an editor to a new location (I dislike the dependency on the text plug-ins, specifically ITextEditor).  Please poke me if I don't post more comments within a week or so.

Comment 24 Vijay Aravamudhan 2006-03-01 18:02:22 EST

Created attachment 35578 [details]
archive export - as per previous comments.

Comment 25 Jeff Myers 2006-03-01 18:50:20 EST

One small comment - it seems to me that you could listen for the first dirty state change on the editor, and when that occurs schedule your save job for it.  In my normal coding usage of eclipse, I'd the majority of editors that I open I never make any changes in, so it seems wasteful to schedule jobs on every editor.

To do this, in your PartListener, instead of newing up your SaveSnapshotJob then, you could add a PropertyListener on the editor.  In the PropertyListener's propertyChanged method you can say:

if (propId == IEditorPart.PROP_DIRTY) {
   IEditorPart editor = (IEditorPart)source;
   new SaveSnapshotJob(editor);
   editor.removePropertyListener(this);
}

Or something like it...

Comment 26 Vijay Aravamudhan 2006-03-02 10:52:13 EST

Created attachment 35615 [details]
v1.0.2: with a couple of bug fixes and a perf enhancement (exp on large projects)

Jeff - thanks for your suggestion, but I noticed that the reconcile action was not triggered till the user started editing the file - and not when the editor was opened for the first time. So I had to schedule the job when the editor is opened.

This version (1.0.2) fixes that as well as another issue where the whole workspace was being refreshed rather than just the directory containing the snapshot file.

Comment 27 Vijay Aravamudhan 2006-03-07 23:04:03 EST

Per comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c23

<poke/>

Comment 28 Vijay Aravamudhan 2006-03-17 22:12:30 EST

hi Doug - do you have any updates on this? You had asked to be pinged in a week's time :)

Comment 29 Vijay Aravamudhan 2006-04-03 12:09:26 EDT

hey Doug,
Is there any progress on this? You had asked to be pinged in a weeks' time - but its more than that now. Just checking.

thanks,
Vijay

Comment 30 Douglas Pollock 2006-04-05 08:16:44 EDT

I'm sorry, but I've moved on to other things.  You're going to have to wait until this bug is re-assigned to someone still working on the Platform/UI team.  I think I know who this will be, so I'll ping them about this bug.

Comment 31 Kim Horne 2006-04-05 08:50:52 EDT

I wont be able to look at this until 3.2 ships but this is definitely something I'd like to see and I don't want the work you guys have done not to be acknowledged.  I am setting up a reminder now to look at this again on June 1.

Comment 32 Vijay Aravamudhan 2006-08-08 11:49:12 EDT

hi Kim,
Just wanted to touch base with you if you have started incorporating this functionality into the main Eclipse platform.

Comment 33 Kim Horne 2006-08-08 13:00:29 EDT

Sorry, there is no timeframe as of yet but I still intend to address this for 3.3

Comment 34 Dani Megert 2006-09-19 07:17:24 EDT

*** Bug 157753 has been marked as a duplicate of this bug. ***

Comment 35 Vijay Aravamudhan 2006-11-01 20:32:27 EST

Bug 154122 seems to have some momentum behind it - maybe this code can be integrated as is or with minimal changes into the core eclipse functionality?

Comment 36 Channing Walton 2006-11-08 16:43:46 EST

(In reply to comment #4)
> Here's how it works: Everytime you switch from one tab to another, or anytime
> IntelliJ loses focus to another application, the file in the editor tab losing
> focus is saved.

Hi, are the any plans to support this behaviour? I started writing a plugin to do this before finding this bug so I don't want to do something that is already planned.

Comment 37 Kim Horne 2007-01-02 08:58:13 EST

Punting to Boris - I believe he's been looking at something in this area.

Comment 38 Boris Bokowski 2007-03-13 16:17:39 EDT

Sorry, but it does not look like I will have time in 3.3 to do anything about this.  I could imagine working on this (with interested parties) in the incubator area, which would make this independent of a particular release.  I'm leaving the 3.3 milestone for now so that I will see this bug again before 3.3 ships.

Comment 39 Boris Bokowski 2007-04-25 15:07:31 EDT

*** Bug 183644 has been marked as a duplicate of this bug. ***

Comment 40 Randy Hudson 2007-04-25 16:22:36 EDT

This should be integrated with the periodic workspace save, which saves preferences and other transient data in the UI. As Jeff Meyers pointed out, it wouldn't make any sense to actually save the resource in its normal place until the user invokes save.

So, why does saveState(IMemento) only exists for IViewPart and not IEditorPart? If it were on the editor, the editor could simply tuck away its working documents. The only thing missing is to enhance IMemento to allow putting of InputStreams (for cases when String wouldn't support the file contents).

Comment 41 Stefan Langer 2007-04-26 08:20:45 EDT

(In reply to comment #40)
> This should be integrated with the periodic workspace save, which saves
> preferences and other transient data in the UI. As Jeff Meyers pointed out, it
> wouldn't make any sense to actually save the resource in its normal place until
> the user invokes save.
This should still be optional since this might result in huge datafiles being written to the metadata area of which the user is not aware.

Comment 42 Randy Hudson 2007-04-26 11:40:23 EDT

> This should still be optional since this might result in huge datafiles being
> written to the metadata area of which the user is not aware.

That happens already with local history. We're only talking about the set of dirty editors only, which is tiny in comparison to the saved workspace. Also, each editor type will have to provide this support, so it won't just start happening everywhere for free.

Comment 43 Boris Bokowski 2007-04-27 08:54:35 EDT

If anybody in the community is interested in working on this, please let me know.

Comment 44 Anton Leherbauer 2007-05-03 08:00:18 EDT

*** Bug 140334 has been marked as a duplicate of this bug. ***

Comment 45 Channing Walton 2007-08-19 15:22:29 EDT

(In reply to comment #36)
> (In reply to comment #4)
> > Here's how it works: Everytime you switch from one tab to another, or anytime
> > IntelliJ loses focus to another application, the file in the editor tab losing
> > focus is saved.

FYI, I've implemented a very simple plugin to support this behaviour. Update site is http://www.stateofflow.com/UpdateSite, the plugin is called SaveMe. You can enable in preferences.

Channing

Comment 46 Vijay Aravamudhan 2007-08-19 18:39:31 EDT

hi Channing,
How is this different from the plugin that I wrote almost a year ago? Are you using any of the new API's for auto save? Not sure what else is different between our two plugins - but if you are interested, we can explore how to merge the two of them.
thanks,
Vijay

Comment 47 Channing Walton 2007-08-20 04:11:09 EDT

(In reply to comment #46)
> hi Channing,
> How is this different from the plugin that I wrote almost a year ago? 

All my plugin does is to save an editor when you switch away from it like IntelliJ does (as I understand it). It does not do what your plugin does and your plugin doesn't seem to do what mine does.


> if you are interested, we can explore how to merge the two of them.

definitely. my plugin is really trivial - I'm happy to send you the code to merge into yours.

channing

Comment 48 Paul Bandler 2008-07-04 08:09:29 EDT

Having just lost most of a morning's work to an as yet unexplained Eclipse crash (second time in recent weeks), went looking for the 'auto-save' feature I felt sure must exist.  When I finally resorted to seaching google, am amazed to find that this deficiency hasn't been addressed on such an otherwise mature platform.

Comment 49 Dani Megert 2008-07-04 08:41:01 EDT

Paul, did you really never save? Maybe you did and you might be able to restore them via local history.

Comment 50 Boris Bokowski 2009-11-17 13:05:56 EST

Remy is now responsible for watching the [EditorMgmt] component area.

Comment 51 Martin Oberhuber 2009-11-25 09:28:58 EST

I have not followed this bug in its entirety, but as per comment 16 there seems to be a solution available in Open SOurce, and as per comment 21 this Open Source solution has even been attached here and released under the EPL. Further more, there is another solution as per comment 45.

In my understanding, the SaveDirtyEditors solution from comment 21 fulfills all the acceptance criteria that I know of. I think it is an advantage that it does *not* save to the Local History.

Boris requested community help in comment 43. I'm not sure what additional help the Community could offer beyond attaching a working solution under EPL here.

What is blocking adoption of this code into the Eclipse code base?

Comment 52 Remy Suen 2009-11-25 12:55:14 EST

(In reply to comment #4)
> Here's how it works: Everytime you switch from one tab to another, or anytime
> IntelliJ loses focus to another application, the file in the editor tab losing
> focus is saved.
(In reply to comment #47)
> All my plugin does is to save an editor when you switch away from it like
> IntelliJ does (as I understand it).

I'm not entirely convinced this is the way to go per comment 11 and comment 14. Those concerns are still valid.

(In reply to comment #40)
> This should be integrated with the periodic workspace save, which saves
> preferences and other transient data in the UI.

I don't think the workbench does this. If the workbench crashes and you restart the workbench state is lost. Unless we're talking about two different things?

http://eclipsenuggets.blogspot.com/2007/09/how-to-save-eclipse-ui-workbench-state_6644.html

(In reply to comment #42)
> Also,
> each editor type will have to provide this support, so it won't just start
> happening everywhere for free.

The current implementation that I've poked at from comment 26 seems to do this automatically for any implementation of an editor which is an instance of an ITextEditor. More end user control via some kind of opt-in mechanism may help though I think it is worth having the actual editor implementation control whether they want to join the autosaving bandwagon or not (hello, ISaveablePart...3?).

(In reply to comment #51)
> Boris requested community help in comment 43. I'm not sure what additional help
> the Community could offer beyond attaching a working solution under EPL here.

Sorry, this is another classic case of "falling through" the cracks (which I will admit we have no excuse for). The bug was opened in 2003 and the component owner for editors has switched around a lot since then (with me being the owner now). I think Boris made his comment 43 during crunch time and didn't give the bug a full pass.

-------------------

I've taken attachment 35615 [details] from comment 26 a spin, maybe these have been addressed in the CVS code?

1. I'm not too gung ho on the default .snapshot suffix. Well, actually, the suffix doesn't really matter to me, I just think it should be hidden by default from the user (by being in some projectName/.snapshots/ folder or whatever). Changing the suffix to "" and prefix to "." doesn't really fly because then you get .Test.java files and JDT gets mad. :) I think having it be in a folder would help with organization.

2. It is possible to get into a "infinite" loop situation.

A. Make a text file in a project.
B. Edit it.
C. Alt+Tab around so the snapshot is made.
D. Open the snapshot file. Edit it.
E. Switch editors to the original file.
F. Switch back to the snapshot file.
G. You get a prompt that the file has changed (presumably because a snapshot operation occurred again?).
H. Click 'No'.
I. Infinite loop between steps G and H.

3. I feel that the snapshot files should be marked as being derived (see IResource's setDerived(boolean) method). If they're not marked as derived, they show up in 'Open Resource' as well as Ctrl+H search results.

4. Changing the prefix/suffix in the preference page should retroactively alter all existing snapshot filenames. Else they will just sit around in the workspace.

5. It seems that the CompareAction no longer works because the workbench page is null. CompareUI should be used instead I think for opening the compare editor.

6. The job's progress monitor should be used for creating the snapshot (instead of having a NullProgressMonitor tossed in).

7. Good to see that the strings are localized. Please migrate them to use the NLS class. Unfortunately, the wiki page eludes me, but you can take a look at org.eclipse.ui.internal.WorkbenchMessages to see how it's used. Please also externalize arguments instead of concatenating them.

Do:

DirtyKey = The file {0} is dirty.

String text = NLS.bind(Messages.DirtyKey, "test.txt");

Don't:

DirtyKey1 = The file 
DirtyKey2 =  is dirty

String text = Messages.DirtyKey1 + "test.txt" + Messages.DirtyKey2.

8. The 'Save As' operation can cause a reconciliation prompt.

A. Create a test.txt.
B. Make some changes.
C. Alt+Tab around to get a snapshot created.
D. File > Save As... > test2.txt > OK
E. test.txt.snapshot is still there.
F. Open test.txt, a reconciliation prompt appears.

9. What's the reason for locking the whole workspace when a snapshot is created (SaveSnapshotJob's run(IProgressMonitor) method)? I would think it is sufficient to just lock the file or its parent container. I may be wrong though.

10. I noticed there's a comment in ReconcileSnapshotAction's run() method that a refresh is required. Is an infinite refresh required or can it just be a first-level refresh? It'd probably also be worth checking why a refresh is needed. :)

11. Checking for an instanceof ITextEditor is insufficient because there are some editors like WST's XML editor that provides both a visual tab and a source tab. Using getAdapter(ITextEditor.class) would be better. Of course, this all ties back to the whole "opt-in opt-out" thing that I mentioned above. As this will directly introduce new API (instead of just a feature change), we would specifically like to request community feedback on this topic so we can perform a thorough assessment, thank you.

There may be other problems (and I think some of the strings wording needs to be worked on) but the above are what I've observed thus far from F3'ing around the code and tire kicking.

Comment 53 Martin Oberhuber 2009-11-25 13:34:08 EST

(In reply to comment #52)
Whow, that's a quick turnaround... thanks Remy!

> 1. I'm not too gung ho on the default .snapshot suffix. Well, actually, the
> get .Test.java files and JDT gets mad. :) I think having it be in a folder
> would help with organization.

-1 for a different folder. 
If Eclipse crashes, you won't be able to associate the files with their original counterparts any more -- at least not easily. In the normal case, the backup will vanish with the next "official" save. So all we care about it the crash case. Prominent examples of prefix/suffix, from the top of my head (some of these may actually be wrong, but that's for example here only):

myfile.txt~  (Emacs)
myfile.txt.keep (ClearCase)
#myfile.txt# (CVS)
myfile.txt.bak (not sure who does this)
myfile.txt.swp (vi if I'm not mistaken)

I'm not sure if we need to keep limitation of any file systems in mind, but I personally like the Emacs way, i.e.
   myfile.txt~
or
   myfile.txt~1~
   myfile.txt~2~
if there are more than one. Keeps the sorting such that the backup is close to the original, and is auto-removed by many "make clean" targets.

> 3. I feel that the snapshot files should be marked as being derived (see
> IResource's setDerived(boolean) method). If they're not marked as derived, they
> show up in 'Open Resource' as well as Ctrl+H search results.

Good idea.

> 4. Changing the prefix/suffix in the preference page should retroactively alter
> all existing snapshot filenames. Else they will just sit around in the
> workspace.

-1 for this suggestion. 
You never get all of them anyways (e.g. if you closed a project). Plus, there are other situations where I need to manually clean up snapshots (e.g. after a crash). Tools like clearcase also don't clean up their .keep files. I think that a user who enables this feature will expect having to manually clean up those guys from time to time. And if I should be mistaken, an  explicit cleanup feature can be added later.

> 7. Good to see that the strings are localized. Please migrate them to use the
> NLS class. 

Good point. If I'm not mistaken there is an automated migration tool for this somewhere.

> 8. The 'Save As' operation can cause a reconciliation prompt.
> D. File > Save As... > test2.txt > OK
> E. test.txt.snapshot is still there.

I think this is the bug... on "Save As", the snapshot should be cleaned.
User deliberately saved modifications under a new name, so expects the old name to be unchanged since the last save (without snapshot).

> 11. Checking for an instanceof ITextEditor is insufficient because there are
> tab. Using getAdapter(ITextEditor.class) would be better. 

Good point. Regarding opt-in / opt-out on a code level, I'm not sure what the benefit of this would be. Users who enable the Preference would expect ALL text editors to be affected, no? I see more potential for confusion with opt-in/opt-out on code level than benefit.

Comment 54 Remy Suen 2009-11-25 14:48:40 EST

(In reply to comment #53)
> -1 for a different folder. 
> If Eclipse crashes, you won't be able to associate the files with their
> original counterparts any more -- at least not easily.

I considered this scenario until I realized that opening any file with a snapshot would give me a reconciliation prompt with the compare editor. I don't feel I should have to be physically aware of a snapshot's existence. The tool should just help me recover the file, I do not care how it makes it happen.

> In the normal case, the
> backup will vanish with the next "official" save.

I do agree with this so perhaps this is not a valid concern. Other feedback more than welcome.

> > 4. Changing the prefix/suffix in the preference page should retroactively alter
> > all existing snapshot filenames. Else they will just sit around in the
> > workspace.
> 
> -1 for this suggestion. 
> You never get all of them anyways (e.g. if you closed a project).

I think for the closed project case I would expect all snapshots to have been _purged_ because the editors are no longer dirty.

> Plus, there
> are other situations where I need to manually clean up snapshots (e.g. after a
> crash).

I'm expecting that the reconciliation will delete the snapshot after I've merged them in the compare editor. Of course, if I don't want that to happen then I could perform manual clean-up.

> I think
> that a user who enables this feature will expect having to manually clean up
> those guys from time to time.

I do admit it may be difficult to implement this and it may be the users' expectation that manual intervention will be required for some cases.

> > 7. Good to see that the strings are localized. Please migrate them to use the
> > NLS class. 
> 
> Good point. If I'm not mistaken there is an automated migration tool for this
> somewhere.

Oh right, there's a string externalization wizard. I rarely use it so I forgot about it.

> Regarding opt-in / opt-out on a code level, I'm not sure what the
> benefit of this would be.

Not everyone edits files in an editor, they may be editing it in a view. The notion of saving and dirty states are not tied to editors, they are tied to saveable parts and views can implement the ISaveablePart interface if they wish. Users may expect their edited files to be backed up but it may not actually happen because the parts are not a "text editor". I think there may be some developers that would want to plug into this auto backup mechanism.

> Users who enable the Preference would expect ALL text
> editors to be affected, no?

By default I would expect the checkbox to be checked and for text editors to have opted in.

Comment 55 Martin Oberhuber 2009-11-25 16:01:11 EST

(In reply to comment #54)
> I considered this scenario until I realized that opening any file with a
> snapshot would give me a reconciliation prompt with the compare editor.

Yes, if you open it in Eclipse again... and perhaps you are right. But I, in the shoes of a developer who's editor just crashed, have a better feeling knowing where the backup file is located than if it's in some obscure folder somewhere. Let alone the complexities of finding a proper name in a folder that's probably shared.

On the other hand, I admit that we've got some customer's request who wanted those backup files all located in one external configurable folder (that was on some extra secure backed-up media if I'm right). Which may make sense in the case of editing files on an NFS share, when the network goes down you'd want your snapshots saved locally.

Comment 56 Martin Oberhuber 2009-11-25 16:02:05 EST

PS wrt automatic reconciliation prompt, when I'm editing files on a shared network drive and the network goes down (and perhaps also Eclipse goes down), it may be not uncommon to have 20 or more files to be reconciled on restart.

Comment 57 Remy Suen 2009-11-25 16:13:03 EST

(In reply to comment #55)
> Which may make sense in the
> case of editing files on an NFS share, when the network goes down you'd want
> your snapshots saved locally.

Good point about NFS and non-local resources (I guess like RSE/TM). Thanks for bringing it up, Martin.

(In reply to comment #56)
> PS wrt automatic reconciliation prompt, when I'm editing files on a shared
> network drive and the network goes down (and perhaps also Eclipse goes down),
> it may be not uncommon to have 20 or more files to be reconciled on restart.

Right, ideally, it should prompt to reconcile all of them at once in a preview dialog (LTK refactoring! :)).

Comment 58 Martin Oberhuber 2010-02-18 09:55:31 EST

Ping, this discussion seems stalled... 

As per comment 52 and the follow-ups, Remy had a few very valid concerns about the contribution as it is attached. So, where are we going to take this?

  a) Can anybody iterate on the contribution until it is acceptable? Or,
  b) Should we have a look at the alternative from Channing (comment 45?) Or,
  c) Should we look at something new which just addresses the basic
     requirement from comment 0 (saving dirty editors to local 
     history in given time intervals)?

Channing: I tried looking at (b) but could not install the feature into Eclipse 3.6m5 (I filed bug 303187 for this issue). Also, as per comment 47, we'd need to get the source under EPL (as per the site, the feature is under CPL).

This has a "helpwanted" keyword, so Community - if you want to see this in Eclipse this year, now is the time to act.

Comment 59 Channing Walton 2010-02-18 16:26:02 EST

(In reply to comment #58)
>  
> Channing: I tried looking at (b) but could not install the feature into Eclipse
> 3.6m5 (I filed bug 303187 for this issue). Also, as per comment 47, we'd need
> to get the source under EPL (as per the site, the feature is under CPL).

I'll have a look at the plugin and see what the problem is. I'd be happy to change the license too.

Comment 60 Martin Oberhuber 2010-02-19 03:30:48 EST

Excellent, Channing - that's great. Could you attach the source here on bugzilla? As you may know, we can only accept contributions coming in via bugzilla.

One little word of caution: The original comment 0 of this bug asks for a time-based autosave, while your contribution saves when the focus changes. So your solution does not cover the case where I'm editing a file, get called away into a meeting (so the editor remains dirty but in focus) and then my computer crashes.

Comment 61 Channing Walton 2010-02-19 04:02:28 EST

Hi,

I originally wrote the plugin to save when focus changed. I'll attach the code for what I have, but I don't think I will have time to do the time-based save at the moment.

(In reply to comment #60)
> Excellent, Channing - that's great. Could you attach the source here on
> bugzilla? As you may know, we can only accept contributions coming in via
> bugzilla.
> 
> One little word of caution: The original comment 0 of this bug asks for a
> time-based autosave, while your contribution saves when the focus changes. So
> your solution does not cover the case where I'm editing a file, get called away
> into a meeting (so the editor remains dirty but in focus) and then my computer
> crashes.

Comment 62 Channing Walton 2010-02-19 04:21:24 EST

Created attachment 159525 [details]
zip of the saveme plugin and feature

Here is the plugin with an EPL. I don't think saving is working with multipage editors - I'll see if I can find the problem.

Comment 63 Jon Green 2014-02-26 05:54:50 EST

I lost a couple of hours'-worth of intense coding this morning, due to a power failure, so this bug - now over ten years old, amazingly - became a rather personal issue.

I note the comments in this bug, and the work-around plugins that people have been contributing.

*This is not a solution.*

It is not reasonable for people needing this feature - pretty-much every Eclipse user, frankly - to have to hunt down a bug report, and download and install a third-party plugin, to have the use of a piece of functionality that started to become standard in code editors more than twenty years ago, and was available in some editors over thirty years ago.

Auto-save of editors should be a mainline functionality feature, not some user-contributed effort. Is there any likelihood - or even a significant possibility - of this happening?

Comment 64 Vijay Aravamudhan 2014-02-27 03:50:55 EST

I am the original author of the SaveDirtyEditors plugin - but, unfortunately, I have not been using Eclipse and not been in Java for the past decade or so. Remy's comments could be valid (I havent gone through them completely), but the usecase for when I wrote the plugin seemed to be satisfied by my plugin. I would request the feature be incorporated into the Core Eclipse product - since I am most likely not going to be able to support this plugin in the near future. If it still works - please use it ;)

Comment 65 Jon Green 2014-02-27 04:38:14 EST

(In reply to Vijay Aravamudhan from comment #64)
> I am the original author of the SaveDirtyEditors plugin [...]
> If it still works - please use it ;)

It does, and I am (CodeWarrior 10.5), and thank you for contributing it.

I absolutely didn't intend to run down the plugins or their authors, by the way. It's just that this is a feature that's been requested for over a decade, and present in other editors for decades more, and nothing in Eclipse has been done. 

No surprise that Android, for instance, has moved onto the rather superior IntelliJ.

Comment 66 Lars Vogel 2015-01-30 08:39:46 EST

I set this as a tentative target for Eclipse 4.5. Auto-save is becoming more and more common and we should support this via a preference (most likely defaulted to its current value)

Comment 67 Filipus Klutiero 2015-01-30 21:46:36 EST

I don't think being ubiquitous is a good reason to implement this at any given time, though it would be most welcome in 4.5. But what current value are you talking about?

Comment 68 Lars Vogel 2015-02-08 18:20:08 EST

This patch uses an model add-on. It registers to the event system of Eclipse 4 to react to the dirty event. If a editor stays dirty for more than 800ms the model add-on saves via the IWorkbenchPage.

Feedback is welcome

https://git.eclipse.org/r/40794

Comment 69 Dani Megert 2015-02-09 04:26:01 EST

(In reply to Lars Vogel from comment #68)
> This patch uses an model add-on. It registers to the event system of Eclipse
> 4 to react to the dirty event. If a editor stays dirty for more than 800ms
> the model add-on saves via the IWorkbenchPage.
> 
> Feedback is welcome
> 
> https://git.eclipse.org/r/40794

I didn't try it but this look like a real performance killer if auto-build is on: it will trigger a build every second.

Comment 70 Lars Vogel 2015-02-09 05:38:41 EST

(In reply to Dani Megert from comment #69)
> I didn't try it but this look like a real performance killer if auto-build
> is on: it will trigger a build every second.

I will only trigger a save (and therefore a build) if there is a dirty editor. I think that is want you want with autosave: if there is a dirty editor save it. Do nothing is there is nothing to save.

Comment 71 Dani Megert 2015-02-09 07:45:51 EST

(In reply to Lars Vogel from comment #70)
> (In reply to Dani Megert from comment #69)
> > I didn't try it but this look like a real performance killer if auto-build
> > is on: it will trigger a build every second.
> 
> I will only trigger a save (and therefore a build) if there is a dirty
> editor. I think that is want you want with autosave: if there is a dirty
> editor save it. Do nothing is there is nothing to save.

Sure, but I might be typing slower than 1s, or have content assist up. You would constantly save and build while I'm typing. Plus, auto save actions might heavily disturb my typing.

Comment 72 Lars Vogel 2015-02-09 08:29:30 EST

(In reply to Dani Megert from comment #71)
> Sure, but I might be typing slower than 1s, or have content assist up. You
> would constantly save and build while I'm typing. Plus, auto save actions
> might heavily disturb my typing.

What is your expected behavior for auto-save?

Comment 73 Dani Megert 2015-02-09 09:44:07 EST

(In reply to Lars Vogel from comment #72)
> (In reply to Dani Megert from comment #71)
> > Sure, but I might be typing slower than 1s, or have content assist up. You
> > would constantly save and build while I'm typing. Plus, auto save actions
> > might heavily disturb my typing.
> 
> What is your expected behavior for auto-save?

I see it as backup in case the user doesn't trigger save and a crash happens. Ideally the file itself is not touched, but a copy is put into the history, or at some other place.

Comment 74 Vijay Aravamudhan 2015-02-09 09:59:29 EST

I am sorry, but my original contribution did all of the above (if i do say so myself) - and, as I stated earlier, I am willing to donate it as is to the Eclipse org - so, why is the wheel being reinvented?

Comment 75 Randy Hudson 2015-02-09 10:46:47 EST

> I see it as backup in case the user doesn't trigger save and a crash
> happens. Ideally the file itself is not touched, but a copy is put into the
> history, or at some other place.

This makes sense to me.  It should be saved as a "draft" copy (the dirty '*' would still appear).  When you restart eclipse, it should check for drafts and reopen them in dirty editors, and/or prompt the user for the appropriate action.

Comment 76 Vijay Aravamudhan 2015-02-09 10:50:44 EST

And that too - the saveDirtyEditors plugin does/did do out of the box. The user could choose to either save to a temp file (where they could specify the prefix/suffix for the filename) or, by keeping that pref value as empty, it would, in effect overwrite the original file. In case of crashes, if the user tried to open the original file, they would be prompted that a dirty copy was available, and the diff comparator would be opened. This is functionality mimicked from vi/vim.

Comment 77 Lars Vogel 2015-02-09 11:54:45 EST

(In reply to Vijay Aravamudhan from comment #76)
> And that too - the saveDirtyEditors plugin does/did do out of the box. The
> user could choose to either save to a temp file (where they could specify
> the prefix/suffix for the filename) or, by keeping that pref value as empty,
> it would, in effect overwrite the original file. In case of crashes, if the
> user tried to open the original file, they would be prompted that a dirty
> copy was available, and the diff comparator would be opened. This is
> functionality mimicked from vi/vim.

Would it be possible to upload your plug-in as Gerrit review? I think it makes sense to integrate that in bundles/org.eclipse.ui.ide. The configuration of Gerrit is not very time-consuming see http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#eclipsegerrit_configuration

Comment 78 Randy Hudson 2015-02-09 12:15:55 EST

Seems like this would have to be an API that editors could adopt.  A single editor might be editing 5 different files at once.

Comment 79 Holger 2015-02-10 17:39:27 EST

(In reply to Lars Vogel from comment #68)
> If a editor stays dirty for more than 800ms


There are two situations it feels too frequent:

- If automatic codeformating is enabled, the short inverval will jump the code around as you type. E.g. manually starting a comment with /* would try to format everything up to the next */ with neet * at the start of every line.

- The compare to local history is absolutely overwhelmed with save events and becomes pretty useless.

Comment 80 Dani Megert 2015-02-11 03:28:49 EST

(In reply to Holger from comment #79)
> (In reply to Lars Vogel from comment #68)
> > If a editor stays dirty for more than 800ms
> 
> 
> There are two situations it feels too frequent:
> 
> - If automatic codeformating is enabled, the short inverval will jump the
> code around as you type. E.g. manually starting a comment with /* would try
> to format everything up to the next */ with neet * at the start of every
> line.
> 
> - The compare to local history is absolutely overwhelmed with save events
> and becomes pretty useless.

The solution should not save/touch the real file at all.