Bug 154122

Comment 1 Dani Megert 2006-08-17 02:46:22 EDT

Moving to Platform UI since this affects all editors not just text, e.g. GEF or VE.

Comment 2 Boris Bokowski 2006-10-11 14:48:21 EDT

Marking as M3 so that I don't forget to investigate what we can do.  Not promising that this will be solved for M3.

Comment 3 Boris Bokowski 2006-10-28 23:14:19 EDT

Created attachment 52912 [details]
work in progress

The interesting cases have to do with closing:  When closing an editor, or a workbench window, or the workbench, you get prompted to save dirty editors.  If the editor (or one of the many you want to close) supports saving in the background, the background save might not succeed in which case we would have to re-open the editor, or defer the closing until the save succeeded.

(The attached patch is really just a work in progress, it does not handle the closing case at all.)

Comment 4 Dani Megert 2006-10-30 03:12:05 EST

Just dropping some scenarios/questions:
- undo history and dirty state: e.g. when I'm in saved state and do this:
  type some text, save, type some text, undo ==> must go back to initial state
  and not be dirty

- starting with M3 JDT Text allows to do clean up on save and in certain 
  situations this can result in a dialog be presented to the user

- error presentation: save editor1 switch to editor2 and then later get a
  dialog for editor1. Q: do we eventually want to restrict background save to 
  the current active editor?

- check whether/how this is related to the auto-save feature request

Comment 5 Edward 2006-11-01 11:22:07 EST

Would be nice to have this ability in the form of an advance local history.

Example:
 Open file for edit
 Edit file
 Close file /or IDE  
 Re-open file / opens most current version, saved or the top of the local
history.

Setting which is presented by default can be a configuration option.

If the user reverts to a previous file state and begins a new line of editing.
show this distinction as a branch in local history window.

This way the user should be able to see the previous edit paths, and there is
not really a need to save on close just check local history is current with the
buffer.

This sounds a little bit like implemented journaling, or Apple's Time Warp. 

Comment 6 Vijay Aravamudhan 2006-11-01 20:22:18 EST

I had implemented something similar - please look at bug: 34076 for attachments/discussions.

Comment 7 Boris Bokowski 2006-11-13 17:40:02 EST

Created attachment 53784 [details]
updated patch, applies to HEAD as of 20061113

Comment 8 Boris Bokowski 2006-12-06 18:22:18 EST

Created attachment 55172 [details]
work in progress, simpler API

Comment 9 Boris Bokowski 2006-12-10 23:36:44 EST

Created attachment 55378 [details]
about to release this patch...

Comment 10 Boris Bokowski 2006-12-10 23:41:05 EST

Released >20061210.  There are probably some remaining kinks to be sorted out before M5, which I will track using separate bugzillas.

Comment 11 Boris Bokowski 2006-12-14 14:54:40 EST

Reopening to track remaining issues.

Comment 12 Boris Bokowski 2007-01-12 15:32:54 EST

Fixed >20070112.  The new API is on org.eclipse.ui.Saveable.  To enable background save for a particular editor, it needs to implement ISaveablesSource, see the Javadoc on Saveable and ISaveablesSource.  An example editor part with background save support is in the Platform/UI test suite, org.eclipse.ui.tests.manual.TestBackgroundSaveEditor.  Its file extension is .background.

Comment 13 Boris Bokowski 2007-01-12 15:42:30 EST

Note that the background save support merely *enables* background save, there is work to be done by editors that want to save in the background.  By default, editors that are saving in the background will have their UI disabled.  Editors that want to allow the user to continue editing should be able to do that, but I don't expect that it will be easy to implement.

(In reply to comment #4)
> Just dropping some scenarios/questions:
> - undo history and dirty state: e.g. when I'm in saved state and do this:
>   type some text, save, type some text, undo ==> must go back to initial state
>   and not be dirty
> 
> - starting with M3 JDT Text allows to do clean up on save and in certain 
>   situations this can result in a dialog be presented to the user
> 
> - error presentation: save editor1 switch to editor2 and then later get a
>   dialog for editor1. Q: do we eventually want to restrict background save to 
>   the current active editor?
> 
> - check whether/how this is related to the auto-save feature request
>