Community
Participate
Working Groups
Here is a proposal for a FIRST implementation of the auto-save in Eclipse: *The auto-save will be disabled by default. Thus, this will be without consequences for Eclipse users. It need feedback of the community to have a clear view of the impact on usage and performance. *The auto-save will only save textual editors. *The auto-save will be active for all textual editors at once. *The auto-save will save dirty editors automatically (based on the keyboard activity). *The period of inactivity before automatic save will be customizable in Eclipse Preferences (from Window > Preferences > General > Editors > Auto-save). *The default value of inactivity before automatic save will be set to 60 seconds. *The minimum value will be 1 second. *The maximum value will be the maximum value of a java integer (2147483647 for a 32-bits JVM). *A warning message will be displayed in case of unauthorized values. *The status bar will provide a quick access to enable/disable the auto-save (by double-click). *This quick access will be only visible for appropriate editors. Here is the wiki link that fully describes the proposition (user story, specification, mock-ups, limitations, possible evolutions): https://wiki.eclipse.org/Platform_UI/AutoSave
A first implementation will be provided soon.
(In reply to Axel RICHARD from comment #0) > *The auto-save will only save textual editors. Then, shouldn't the new Auto-Save preference page appear under Text Editors?
I'm interested in this since I use auto-save all the time now in Orion and I've come to love it :) One thing you'll have to look out for is the interaction of auto-save with local history. If I set the auto-save to 1 sec (as I would) I don't want the local history to get spammed with 2-3 char diffs. Perhaps you could implement a 'generate local history' timer set at say 5 mins so that we only generate a local history record if the file has changed since the last record was generated and it's been > 5 mins.
(In reply to Axel RICHARD from comment #0) > *The auto-save will only save textual editors. Is this a limitation you're planning to drop in a next iteration? I believe the save behavior must be consistent between all editors for a more unified user experience. So in fine, this constraint will most likely have to disappear. Isn't it actually more complicated to set up that restriction than it is to apply auto-save on all editors? What about multi-page editors with a form and a text (such as pom.xml) ?
(In reply to Eike Stepper from comment #2) > (In reply to Axel RICHARD from comment #0) > > *The auto-save will only save textual editors. > > Then, shouldn't the new Auto-Save preference page appear under Text Editors? Eike, I asked the same question to myself. In the future steps, the auto-save will possibly save various kinds of editors, not only text editors. If we put the preference page under 'Text Editors', we should then move it in the future under 'Editors'. Some users could be troubled by this change. So I think it is better that the preference page appears under 'Editors' and not under 'Text Editors', It will allow to not trouble users habits.
(In reply to Axel RICHARD from comment #5) That sounds reasonable to me. Thanks for the clarification ;-)
(In reply to Eric Moffatt from comment #3) > I'm interested in this since I use auto-save all the time now in Orion and > I've come to love it :) > > One thing you'll have to look out for is the interaction of auto-save with > local history. If I set the auto-save to 1 sec (as I would) I don't want the > local history to get spammed with 2-3 char diffs. > > Perhaps you could implement a 'generate local history' timer set at say 5 > mins so that we only generate a local history record if the file has changed > since the last record was generated and it's been > 5 mins. I totally understand your concerns, but as part of the FEEP initiative, we can't handle all the whole problematic with the time given. That's why it is a first iteration and may be others iterations will come with next FEEP rounds. Thanks for understanding.
(In reply to Mickael Istria from comment #4) > (In reply to Axel RICHARD from comment #0) > > *The auto-save will only save textual editors. > > Is this a limitation you're planning to drop in a next iteration? I believe > the save behavior must be consistent between all editors for a more unified > user experience. So in fine, this constraint will most likely have to > disappear. > Isn't it actually more complicated to set up that restriction than it is to > apply auto-save on all editors? > What about multi-page editors with a form and a text (such as pom.xml) ? Mickael, As part of the FEEP initiative, we can't handle all the whole problematic with the time given. That's why it is a first iteration and may be others iterations will come with next FEEP rounds. Thanks for understanding.
(In reply to Axel RICHARD from comment #8) > As part of the FEEP initiative, we can't handle all the whole problematic > with the time given. That's why it is a first iteration and may be others > iterations will come with next FEEP rounds. Thanks for understanding. Sure, I understand. However, I'm technically curious about why is limiting support to text editor simpler than leaving it open. If your implementation is relying on the save command; what's the difference between a text and a diagram editor?
I think a pure time-based approach based on the keyboard activity is wrong. I have uploaded a similar approach to https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c68 but Dani right fully rejected that approach. I did not find the time to review the existing contribution from Vijay Aravamudhan (see for example https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c74) Axel, did you review Vijay code?
(In reply to Axel RICHARD from comment #0) > Here is a proposal for a FIRST implementation of the auto-save in Eclipse: > > *The auto-save will only save textual editors. > > Here is the wiki link that fully describes the proposition (user story, > specification, mock-ups, limitations, possible evolutions): > https://wiki.eclipse.org/Platform_UI/AutoSave There's a few key UI aspects that are not described there. For example, does auto-save save to the same file that the editor is editing, or to a backup location elsewhere? I'm assuming it's the former since another concern mentioned in the wiki is possible interactions with the auto-build feature (that is only a concern if saving to the same file). However, in any case this aspect should be mentioned explicitly. What happens to the UI dirty state of an editor when it's auto-saved? Does the editor become non-dirty? Or is the save just done internally/transparently? Also, what about due diligence of technical feasibility? That is, what about - before discussing how the preference page for the auto-save feature will work (which is of minor importance anyways) - we check about the technical feasibility, implementation wise, of auto-save in the current Platform code. It's important to get a bearing early on of how hard this would be to implement, and what the implications could be for the rest of Platform behavior and API. I'll give a concrete example, based upon my earlier explorations on this feature: Saving a file as it's currently implemented is an action that is performed in the UI thread. This means the UI thread may be blocked by a minuscule amount of time, but possibly a noticeable one (20-100ms). This is currently fine because a save is only invoked after some manual user action (like saving the editor, or building the workspace). So it's ok if the user experiences that small delay when saving a file. However once we add a feature that makes a save happen automatically, especially if we want auto-save to happen frequently, such delays would be extremely detrimental to the user experience (if not downright unadmissable). As such the file save should happen on a background thread. And this brings up the issue of whether the Platform API is ready to handle that. In theory it should, but this needs to be looked at. Hopefully someone with experience on this aspect of the API could comment on it, but it needs to be looked at properly in any case. Because even if the ITextFileBuffer's can be saved on a background thread, they still fire listener events to some of listeners (and now those events would be triggered outside the UI thread). This could potentially be a breaking change, if the listeners assume they are only triggered in UI thread. Last time I looked at the Platform code (ITextFileBuffers, IDocument's and related stuff), it was quite hard to figure what the actual concurrency constraints where.
(In reply to Mickael Istria from comment #9) > (In reply to Axel RICHARD from comment #8) > > As part of the FEEP initiative, we can't handle all the whole problematic > > with the time given. That's why it is a first iteration and may be others > > iterations will come with next FEEP rounds. Thanks for understanding. > > Sure, I understand. However, I'm technically curious about why is limiting > support to text editor simpler than leaving it open. If your implementation > is relying on the save command; what's the difference between a text and a > diagram editor? +1. I don't see how the restriction makes it easier for you. As outlined in bug 34076 the solution should simply save the files periodically in the background so that the current user experience stays the same. No impact on dirty state or performance due to constant builds. Only when the IDE crashes those files are used to restore the last saved state.
(In reply to Dani Megert from comment #12) > As outlined in bug 34076 the solution should simply save the files > periodically in the background so that the current user experience stays the > same. No impact on dirty state or performance due to constant builds. > > Only when the IDE crashes those files are used to restore the last saved > state. I think that is not the desired outcome for the user. My understanding of the requirement is that the usage of Ctrl+S or the save button can be avoided. Similar to IntelliJ, in which the user never has to select the save operation and an editor never gets dirty. I think you are describing a different feature. Not "auto-save" but "a better way to recover user changes in case of a crash", which I think is not scope of this bug and FEEP.
(In reply to Lars Vogel from comment #13) > I think you are describing a different feature. Not "auto-save" but "a > better way to recover user changes in case of a crash", which I think is not > scope of this bug and FEEP. The FEEP came out of bug 34076 where many different approaches are discussed. Maybe a poll should be done before investing to much into one or the other solution. Note that besides the obvious performance hit with the proposed solution where save happens on the real editor and in the UI , it will drive all users who use Save Actions mad, because in the middle of typing it will reformat their code. Bummer!
(In reply to Dani Megert from comment #14) > Note that besides the obvious performance hit with the proposed solution > where save happens on the real editor and in the UI , it will drive all > users who use Save Actions mad, because in the middle of typing it will > reformat their code. Bummer! I don't think it's that much a bummer. Maybe at usage, it will become comfortable to see the code reorganized correctly just as we type, rather than a bulk operation on save. A benefit of immediate actions is that they are also more "pedagogic" than delayed correction. And for sure users' habits will change if they come to use the auto-save. Probably they'll use save action less and less. In any case, they'll do what they want since they have always had choice... So I don't believe this issue about save action is something that should be taken into account right now. It will be easier to see how good/bad it is once there is an implementation working.
(In reply to Dani Megert from comment #14) > (In reply to Lars Vogel from comment #13) > > I think you are describing a different feature. Not "auto-save" but "a > > better way to recover user changes in case of a crash", which I think is not > > scope of this bug and FEEP. > > The FEEP came out of bug 34076 where many different approaches are > discussed. Maybe a poll should be done before investing to much into one or > the other solution. I would suggest that the foundation should clarify the scope of the development with Axel and the Eclipse PMC, as they paying for it. > Note that besides the obvious performance hit with the proposed solution > where save happens on the real editor and in the UI , it will drive all > users who use Save Actions mad, because in the middle of typing it will > reformat their code. Bummer! I agree that this is one of the challenges how to implement this. My first guess would be that save actions and auto-save should be exclusive options, but maybe looking at how other IDEs handle that might bring up better ideas.
(In reply to Mickael Istria from comment #15) > A benefit of immediate actions is that they are also more "pedagogic" than delayed correction. Typing an open comment /* will wreak havoc on the rest of the file ... at least it makes for a good excuse to not document your code anymore :-) (In reply to Lars Vogel from comment #13) > I think you are describing a different feature. Not "auto-save" but "a > better way to recover user changes in case of a crash", which I think is not > scope of this bug and FEEP. Right, but in absence of the second, I'd try to use the first as a poor man's crash recovery, though given the choice, I'd prefer Dani's suggestion as the real thing. Maybe that is why I felt 60 sec is way to short and I already envisioned myself setting it to about 15-20 minutes, to give me enough time to do my normal manual saves as I'm used to and only cover up should I walk off to lunch without saving. (In reply to Axel RICHARD from comment #0) > *The auto-save will save dirty editors automatically (based on the keyboard activity). Axel, can you please confirm: Keyboard-activity will reset the timer, so the timeout won't ever expire, as long as I still type another letter every 59 seconds?
(In reply to Mickael Istria from comment #9) > (In reply to Axel RICHARD from comment #8) > > As part of the FEEP initiative, we can't handle all the whole problematic > > with the time given. That's why it is a first iteration and may be others > > iterations will come with next FEEP rounds. Thanks for understanding. > > Sure, I understand. However, I'm technically curious about why is limiting > support to text editor simpler than leaving it open. If your implementation > is relying on the save command; what's the difference between a text and a > diagram editor? Mickael, For example, a save of a Sirius editor (diagram editor) implies a save of a Sirius Session (see https://www.eclipse.org/sirius/doc/developer/Architecture.html#session), which is potentially costly in time and memory. You can imagine the same with a CDO session and many other technologies.
(In reply to Axel RICHARD from comment #18) > For example, a save of a Sirius editor (diagram editor) implies a save of a > Sirius Session (see > https://www.eclipse.org/sirius/doc/developer/Architecture.html#session), > which is potentially costly in time and memory. You can imagine the same > with a CDO session and many other technologies. Ok. I believe that for a 1st iteration, it's more user-friendly to offer a consistent save behavior for editors, even if some of them may take time and pop-up a dialog from time to time; than to have different processes for different editors. By the way, you may consider allow the save operation for those editors a background and non-blocking operation, so user wouldn't even notice that saving operation. A command parameter could be used to explicit the need for a "background" save.
(In reply to Lars Vogel from comment #10) > I think a pure time-based approach based on the keyboard activity is wrong. > I have uploaded a similar approach to > https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c68 but Dani right fully > rejected that approach. > > I did not find the time to review the existing contribution from Vijay > Aravamudhan (see for example > https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c74) > > Axel, did you review Vijay code? Lars, yes I saw your contribution and the refusal of Dani. I don’t see in the comment of the associated review why it is a wrong approach. Can you share with us why you think that ? About the Vijay code, It is an old development and not a platform UI contribution. After imported the code, I didn’t succeed to run the plugin. It is may minor things to fix, or not, I don’t know. There are probably good ideas in his code that will help me.
(In reply to Bruno Medeiros from comment #11) > What happens to the UI dirty state of an editor when it's auto-saved? Does > the editor become non-dirty? Or is the save just done > internally/transparently? When the editor is save by the auto-save, it will become non dirty (like a ‘manual’ save).
(In reply to Holger from comment #17) > > Axel, can you please confirm: Keyboard-activity will reset the timer, so the > timeout won't ever expire, as long as I still type another letter every 59 > seconds? Yes I confirm this behavior.
(In reply to Lars Vogel from comment #16) > (In reply to Dani Megert from comment #14) > > (In reply to Lars Vogel from comment #13) > > > I think you are describing a different feature. Not "auto-save" but "a > > > better way to recover user changes in case of a crash", which I think is not > > > scope of this bug and FEEP. > > > > The FEEP came out of bug 34076 where many different approaches are > > discussed. Maybe a poll should be done before investing to much into one or > > the other solution. > > I would suggest that the foundation should clarify the scope of the > development with Axel and the Eclipse PMC, as they paying for it. > > > Note that besides the obvious performance hit with the proposed solution > > where save happens on the real editor and in the UI , it will drive all > > users who use Save Actions mad, because in the middle of typing it will > > reformat their code. Bummer! > > I agree that this is one of the challenges how to implement this. My first > guess would be that save actions and auto-save should be exclusive options, > but maybe looking at how other IDEs handle that might bring up better ideas. Lars, Dani, everybody, The Eclipse Foundation has missioned us to provide a first implementation of the auto-save. The scope accepted by the Eclipse Foundation is: - A first step of the auto-save in Eclipse IDE, which can be largely tested and try. This project will be to make a short specification of the expected behavior for a first run. This work will: - select one user story from the bug discussions - make a user experience specification (with functional scope and limitations) - propose some UI mockups - the proposed behavior is to not activate this feature by default because it need feedback of the community to have a clear view of the impact on usage and performance. - as JDT is the most popular editors, we will focus our work on this editor. The autosave features for Java editor will be implemented based on the choice made during the specification step. - the crash recovery will be out of scope - the impact of auto-save with local history, auto-build, auto-format … will be out of scope - at the end of work, a short report will be created to explain the result, its limitations, and a first proposition of what could be a more generic architecture to take in account other kinds of editors At first sight, It is not much more complicated to have the auto-save for all text editors not JDT only, this is why I propose to have the auto-save in Platform UI instead of JDT UI. If you, Platform UI leaders think I should only handle JDT editors for this first iteration, I will move the bug in JDT UI. If you’re ok, I’ll try, in a first contribution, to handle text editors. Then, based on this on the first contribution, we’ll see what can be improved or added. The idea of our work as part of the FEEP initiative is to provide a first implementation of the auto-save, which will have a very simple behavior and will be without consequences for the users. That’s why the feature will not be active by default. That’s why the default value of the countdown I proposed is set to 60 seconds. That’s why the value of the countdown will be modifiable. That’s why we will not handle crash recovery, local history, background saving… for this first iteration. I think we should provide a first version of the auto-save as I proposed in this ticket, and then gather the community feedback. Then, based on this feedback, we (the community) will improve the auto-save. The initial bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076 has been reported in 2003 and there’s still no auto-save in Eclipse IDE. I agree this is a complex subject, but after 13 years of discuss, may be It is time to try something. That’s what the FEEP initiative want to do.
(In reply to Axel RICHARD from comment #20) > (In reply to Lars Vogel from comment #10) > > I think a pure time-based approach based on the keyboard activity is wrong. > > I have uploaded a similar approach to > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c68 but Dani right fully > > rejected that approach. > > > > I did not find the time to review the existing contribution from Vijay > > Aravamudhan (see for example > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c74) > > > > Axel, did you review Vijay code? > > Lars, yes I saw your contribution and the refusal of Dani. I don’t see in > the comment of the associated review why it is a wrong approach. > Can you share with us why you think that ? > I share the concerns about local history. But more importantly, auto-save should IMHO not a "delayed" time based save but consider other user interactions as well. For example if I enable auto-save and start my Java program via Ctrl + F11, I don't want to see a popup asking me if I want to save. In general all actions in which I leave the current editor or trigger an command/ action should save the editor.
Axel, to your other question, I think the Platform UI project (which includes platform.text) is the right place to handle the devrlopment, doing this in JDT would IMHO wrong.
(In reply to Lars Vogel from comment #24) > But more importantly, auto-save should IMHO not a "delayed" time based save > but consider other user interactions as well. For example if I enable > auto-save and start my Java program via Ctrl + F11, I don't want to see a > popup asking me if I want to save. In general all actions in which I leave > the current editor or trigger an command/ action should save the editor. Yes, I'm agree, another example is the closing of a dirty editor who prompt to the user a dialog "XXX has been modified. Save Changes ?". If, in these cases, the auto-save preference state is enabled, then the prompt dialog could be not launched. I think this is compatible with my proposition. I will think about other similar cases, and see if it is possible to handle it.
(In reply to Axel RICHARD from comment #23) > Lars, Dani, everybody, > > The Eclipse Foundation has missioned us to provide a first implementation of > the auto-save. > > The scope accepted by the Eclipse Foundation is: > > - A first step of the auto-save in Eclipse IDE, which can be largely tested > and try. This project will be to make a short specification of the expected > behavior for a first run. This work will: > - select one user story from the bug discussions Why not ask the community before you choose a scenario? The proposed solution must work for all editors in the Eclipse SDK (including PDE editors), but also for editors that are based on the Structured Source Editor framework from WTP (e.g. XML editor). > - as JDT is the most popular editors, we will focus our work on this editor. Auto-save is a platform concept that needs to work for most (if not all) editors. > - the crash recovery will be out of scope That was one of (if not) the major concern/request in the original bug 34076. Ignoring that is taking the original bug report into a wrong direction. > That’s why the feature will not be active by default. +1
(In reply to Dani Megert from comment #27) > (In reply to Axel RICHARD from comment #23) > > Lars, Dani, everybody, > > > > The Eclipse Foundation has missioned us to provide a first implementation of > > the auto-save. > > > > The scope accepted by the Eclipse Foundation is: > > > > - A first step of the auto-save in Eclipse IDE, which can be largely tested > > and try. This project will be to make a short specification of the expected > > behavior for a first run. This work will: > > - select one user story from the bug discussions > > Why not ask the community before you choose a scenario? > > > The proposed solution must work for all editors in the Eclipse SDK > (including PDE editors), but also for editors that are based on the > Structured Source Editor framework from WTP (e.g. XML editor). Dani, thank you for your answer. The initial bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076 has been reported in 2003 and there’s still no auto-save in Eclipse IDE. That shows it is very hard to find an ideal solution that is suitable for everyone from the beginning. I think three choices are possible: 1) we implement and push a limited feature for Neon, but a working one. 2) we propose a vote, make specifications based on this vote for a more generic solution which will try to handle all use cases and editors, but with no functional feature in the short term. 3) we propose the feature only for the JDT, not for all textual editors, in agreement with our initial proposal to the FEEP. Today, it is impossible to reach the second choice with the Neon’s schedule and the FEEP’s budget, and it seems very hard to me to get a consensus without a first working limited feature. The first choice seems the most reasonable, if we take care to implement a solution that will be enough open and generic to handle all use cases and editors. Regards,
(In reply to Axel RICHARD from comment #28) > (In reply to Dani Megert from comment #27) > > (In reply to Axel RICHARD from comment #23) > > > Lars, Dani, everybody, > > > > > > The Eclipse Foundation has missioned us to provide a first implementation of > > > the auto-save. > > > > > > The scope accepted by the Eclipse Foundation is: > > > > > > - A first step of the auto-save in Eclipse IDE, which can be largely tested > > > and try. This project will be to make a short specification of the expected > > > behavior for a first run. This work will: > > > - select one user story from the bug discussions > > > > Why not ask the community before you choose a scenario? > > > > > > The proposed solution must work for all editors in the Eclipse SDK > > (including PDE editors), but also for editors that are based on the > > Structured Source Editor framework from WTP (e.g. XML editor). > > Dani, thank you for your answer. > > The initial bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076 has been > reported in 2003 and there’s still no auto-save in Eclipse IDE. That shows > it is very hard to find an ideal solution that is suitable for everyone from > the beginning. > I think three choices are possible: > 1) we implement and push a limited feature for Neon, but a working one. > 2) we propose a vote, make specifications based on this vote for a more > generic solution which will try to handle all use cases and editors, but > with no functional feature in the short term. > 3) we propose the feature only for the JDT, not for all textual editors, in > agreement with our initial proposal to the FEEP. > > Today, it is impossible to reach the second choice with the Neon’s schedule > and the FEEP’s budget, and it seems very hard to me to get a consensus > without a first working limited feature. > The first choice seems the most reasonable, if we take care to implement a > solution that will be enough open and generic to handle all use cases and > editors. 3) is no option for me. 1) depends on the scope of "limited". As said, it must at least work for all editors in the SDK and SSEs.
(In reply to Axel RICHARD from comment #28) > 1) we implement and push a limited feature for Neon, but a working one. > 2) we propose a vote, make specifications based on this vote for a more > generic solution which will try to handle all use cases and editors, but > with no functional feature in the short term. > 3) we propose the feature only for the JDT, not for all textual editors, in > agreement with our initial proposal to the FEEP. 1 is the best solution, however I don't support your definition of "limited" to only some editors. Having a hybrid behavior with editors behaving differently inside the same workspace is really not a pleasant user-experience. Users won't understand why some are working, some other not and it will drive them crazy so they'll either forget to save some editors, or always use Ctrl-S (which is exactly the opposite purpose of this issue). I believe that a solution that would save ALL editors, even if some (Sirius, CDO...) are not responsive enough is a better first iteration than adding "filters" on the feature to hide the fact that some editors require tweaks. Both from design and user point of view. If you want to make sure an issue (such as the save "lag" for some editor) get fixed, the first step is to make it visible.
(Hum, for some reason I forgot to add me to CC, so missed all the newer comments) (In reply to Mickael Istria from comment #15) > > I don't think it's that much a bummer. Maybe at usage, it will become > comfortable to see the code reorganized correctly just as we type, rather > than a bulk operation on save. I disagree. I think it's a really bad idea to have auto-save trigger save actions. Furthermore some editors/IDEs may have save actions that don't preserve the editor cursor position (might be rare, but we have to cater for that scenario), so having save-actions implicitly triggered as the user types (or after a delay), would be very annoying. I think even the first iteration of the auto-save functionality should avoid triggering save-actions. Maybe some advanced IDEs would be able to have save actions as the user types, but that shouldn't be the default behavior.
(In reply to Dani Megert from comment #27) > > > - as JDT is the most popular editors, we will focus our work on this editor. > > Auto-save is a platform concept that needs to work for most (if not all) > editors. > I agree. > > - the crash recovery will be out of scope > > That was one of (if not) the major concern/request in the original bug > 34076. Ignoring that is taking the original bug report into a wrong > direction. > > I think there is some miscommunication here. If auto-save is implemented by saving directly to the original file (like IntelliJ IDEA does), then the crash recovery *user scenario* is automatically handled - because if Eclipse crashes, when it's restarted the original files will obviously already have a recent version of the last edited version (at most only a few minutes or seconds old). I think what Alex meant when he said "crash recovery will be out of scope" is that it's out of scope to try to implement a functionality that works only by saving dirty editors into separate, backup locations/files (and restoring them if Eclipse crashes).
(In reply to Dani Megert from comment #29) > (In reply to Axel RICHARD from comment #28) > > (In reply to Dani Megert from comment #27) > > > > Dani, thank you for your answer. > > > > The initial bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076 has been > > reported in 2003 and there’s still no auto-save in Eclipse IDE. That shows > > it is very hard to find an ideal solution that is suitable for everyone from > > the beginning. > > I think three choices are possible: > > 1) we implement and push a limited feature for Neon, but a working one. > > 2) we propose a vote, make specifications based on this vote for a more > > generic solution which will try to handle all use cases and editors, but > > with no functional feature in the short term. > > 3) we propose the feature only for the JDT, not for all textual editors, in > > agreement with our initial proposal to the FEEP. > > > > 3) is no option for me. 1) depends on the scope of "limited". As said, it > must at least work for all editors in the SDK and SSEs. Dani, all, Ok, I will update the specification page with your demands. So, it must at least work for all editors in the SDK and SSEs. I also propose to start the work upon the contribution of Lars (https://git.eclipse.org/r/40794) instead of restart from the beginning. Regards,
(In reply to Axel RICHARD from comment #33) > I also propose to start the work upon the contribution of Lars > (https://git.eclipse.org/r/40794) instead of restart from the beginning. Of course, reusing my Gerrit is fine for me.
Just to let everyone know, I'm doing some parallel work on the auto-save functionality. This is because I have a specific requirement that is out of scope (as things stand) for the FEEP: * I want to be able to auto-save editors on-the-fly, that is, immediately, as the user types (no delay). This is for a use case particular to several IDES I work on (for Go, D, Rust), that all use external tools for building, code completion, analysis, etc., and long story short: some advanced functionality requires keeping the editor buffers in-sync with the underlying files as soon as possible. This means Lars' prototype, or anything else that uses the ISaveablePart.doSave(IProgressMonitor) layer, directly or indirectly, is not suitable. That's because that method has to be called from the UI thread, and doing on-the-fly auto-save requires the save to be performed on the background, otherwise the UI would become sluggish/unresponsive. There is also the problem that there is no way to prevent triggering save-actions, and local-history snapshots, when using #ISaveablePart.doSave(IProgressMonitor). (as far as I know at least) I've written an alternate prototype that works by hooking into the ITextFileBufferManager layer. It listens to when new documents are created, and then for those documents it listens for document change events. Whenever such document changes happens, a request to save the file is sent to a background worker thread. The actual save is made using IFileBuffer API. The editor/parts API is bypassed completely. The first iteration of the prototype used IFileBuffer.commit(IProgressMonitor, boolean) to perform the save, but that turned to not work, it has subtle UI concurrency bugs: it triggers ITextFileBufferManager listener events outside the UI thread, and those listeners are not meant to be triggered that way. A proper version of my AutoSaveManager necessitated changes to the IFileBuffer, namely the addition of a method that commits the file, but doesn't trigger the listeners. You can see this version of the manager here: https://github.com/bruno-medeiros/MelnormeEclipse/blob/e14eb9280d08b8b3f8c6b4c10b92daaa28cd564e/plugin_ide.core/src-lang/melnorme/lang/ide/core/engine/AutoSaveManager.java I'm gonna submit a Gerrit patch of the IFileBuffer changes next, for consideration. Those should be helpful even if using a different auto save implementation. This AutoSaveManager is not complete though, as certain concurrent scenarios are not guaranteed to work correctly all the time (such as a manual save requested in super quick succession after document changes). I want to make it 100% correct, but it will further necessitate more IFileBuffer API changes. I'd like to get some feedback on the initial changes first though.
New Gerrit change created: https://git.eclipse.org/r/66336
(In reply to Eclipse Genie from comment #36) > New Gerrit change created: https://git.eclipse.org/r/66336 Hello Bruno, Thanks for your proposal. As it is not the same scope than the proposal of this enhancement ticket (see comment 1), could you open a new bug and associate your gerrit review with this new bug please ? On my side, I will push a first implementation soon. Regards,
(In reply to Bruno Medeiros from comment #35) > A proper version of my AutoSaveManager necessitated changes to the > IFileBuffer, namely the addition of a method that commits the file, but > doesn't trigger the listeners. You can see this version of the manager here: > https://github.com/bruno-medeiros/MelnormeEclipse/blob/e14eb9280d08b8b3f8c6b4c10b92daaa28cd564e/plugin_ide.core/src-lang/melnorme/lang/ide/core/engine/AutoSaveManager.java Not sending the events is a no go. That would leave/put all buffer listeners into an inconsistent state, e.g. dirty state of editors, refactorings that currently work on files (not open in any editor), etc.
(In reply to Dani Megert from comment #38) > (In reply to Bruno Medeiros from comment #35) > > A proper version of my AutoSaveManager necessitated changes to the > > IFileBuffer, namely the addition of a method that commits the file, but > > doesn't trigger the listeners. You can see this version of the manager here: > > https://github.com/bruno-medeiros/MelnormeEclipse/blob/e14eb9280d08b8b3f8c6b4c10b92daaa28cd564e/plugin_ide.core/src-lang/melnorme/lang/ide/core/engine/AutoSaveManager.java > > Not sending the events is a no go. That would leave/put all buffer listeners > into an inconsistent state, e.g. dirty state of editors, refactorings that > currently work on files (not open in any editor), etc. Not exactly. Note that with those changes there are now two levels of saving, the full save (the normal save as we know it, saves and does everything, notifies listeners, etc.), and a partial, or lets call it internal save. (That does not notify listeners - nor saves the annotation model BTW). When this internal save occurs, the dirty state of the buffer does not change either (it remains dirty). As such the UI still thinks its dirty (in a way it is), which means the user is still forced to save the editor manually. When such a manual save occurs, a full-save is performed, which will notify listeners and make everything consistent. This is not the ideal end-picture for the UI behavior, since after all we want to remove explicit saving, but the behavior above can then be combined with another auto-save mechanism that performs the full-save on a regular interval (or when an editor frame is deactivated), which is pretty much what we've been discussing already.
(In reply to Axel RICHARD from comment #37) > (In reply to Eclipse Genie from comment #36) > > New Gerrit change created: https://git.eclipse.org/r/66336 > > Hello Bruno, > > Thanks for your proposal. As it is not the same scope than the proposal of > this enhancement ticket (see comment 1), could you open a new bug and > associate your gerrit review with this new bug please ? On my side, I will > push a first implementation soon. > > Regards, Ok: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487653
New Gerrit change created: https://git.eclipse.org/r/66465
New Gerrit change created: https://git.eclipse.org/r/66742
Axel, I will give it a try and give you some feedback shortly (probably tomorrow)
Great, thanks Mikaël !
I've given a first test to your review. It already works well. However, I've some concerns: - I don't see the behavior described in comment 17 and that you (Axel) confirmed in comment 22. The autosave is triggered after the end of the timer regardless of my keyboard activity. It does no seem to be reset. This is really annoying. I've managed to see this behavior by setting the autosave timer to a low value. - I've tried editing some java code with "save actions / formatter" enabled. It is really confusing, especially because the caret does not always retain its location after a save. This behavior is even worst because of the behavior described above (the autosave is triggered in the middle of my typing). I'm not sure the conflict with "saves actions" should be addressed in this initial version. At least, a warning notice about this disturbing behavior should be displayed on the preference page. - The "quick access" in the status bar requires a double click (as specified in https://wiki.eclipse.org/Platform_UI/AutoSave#Behavior). I think it will be simpler to require a single click (I initially tried a single click and thought the button was broken). Also, when activating the autosave from this location, it would be great to open a popup with the warning notices described in the preference page. It would be even greater to let user check a box to say whether they want popup should be displayed next they activate auto-save.
(In reply to Mikael Barbero from comment #45) > - The "quick access" in the status bar requires a double click (as specified > in https://wiki.eclipse.org/Platform_UI/AutoSave#Behavior). I think it will > be simpler to require a single click (I initially tried a single click and > thought the button was broken). Also, when activating the autosave from this > location, it would be great to open a popup with the warning notices > described in the preference page. It would be even greater to let user check > a box to say whether they want popup should be displayed next they activate > auto-save. There is no reason that justifies adding this preference into the status bar or anywhere in the workbench window. It is a preference/feature like any other, which a user will either enable or disable. If everyone would put its preference into the workbench window, then it would be big mess. Please remove it. By the way, on Windows one can hardly see it (see attached screenshot).
I've done an initial review of the feature and captured it in https://git.eclipse.org/r/#/c/66742/ The main concerns mentioned there are: - One big show stopper is that the auto-save operation terminates many existing actions (closes their shell), e.g. content assist, hover, Quick Fix/Assist, linked mode etc. This will not be accepted by the users. - As mentioned before, using this together with Auto Save is almost impossible due to the unexpected caret movement.
Created attachment 259823 [details] Strange looking auto-save status bar item (Windows 7) NOTE: Do not try to fix it. Just get rid of it.
(In reply to Dani Megert from comment #47) > I've done an initial review of the feature and captured it in > https://git.eclipse.org/r/#/c/66742/ > > The main concerns mentioned there are: > > - One big show stopper is that the auto-save operation terminates many > existing actions (closes their shell), e.g. content assist, hover, Quick > Fix/Assist, linked mode etc. This will not be accepted by the users. > > - As mentioned before, using this together with Auto Save is almost > impossible due to the unexpected caret movement. Hello, In https://git.eclipse.org/r/#/c/66742/, the SaveAllDirtyPartsAddon class has an IEventBroker that subscribes to UIEvents.Dirtyable.TOPIC_DIRTY, but this is not the right event to subscribe, because when an editor is already dirty, then a change in this editor will not send another dirty event. I need to subscribe to any change in an (active) editor. Is anybody can help me about this ? Thanks in advance Best Regards,
New Gerrit change created: https://git.eclipse.org/r/67669
(In reply to Dani Megert from comment #47) > I've done an initial review of the feature and captured it in > https://git.eclipse.org/r/#/c/66742/ > > The main concerns mentioned there are: > > - One big show stopper is that the auto-save operation terminates many > existing actions (closes their shell), e.g. content assist, hover, Quick > Fix/Assist, linked mode etc. This will not be accepted by the users. > > - As mentioned before, using this together with Auto Save is almost > impossible due to the unexpected caret movement. Hello I just pushed a new version of the contribution for the auto-save in Eclipse. It takes the comments into account, except the one about the termination of existing actions (e.g. content assist...). As said in the comment 45, I don't think the conflict with "saves actions" should be addressed in this initial version. About this new version, I introduced a new event Last_Modified to let users know that a part has been modified. I also introduced a new ISaveablePart3 that inherits from ISaveablePart. Do not hesitate to review and comment this new version of the contribution. Best Regards,
As you can see, the change is now also affecting the AbstractTextEditor in the platform text repository. So the change is in two parts : https://git.eclipse.org/r/66742 (Platform UI) https://git.eclipse.org/r/67669 (Platform Text)
(In reply to Axel RICHARD from comment #51) > It takes the comments into account, except the one about the termination of > existing actions (e.g. content assist...). Sorry, but this is a no go. Let me know when you have something that doesn't interrupt those, and I will take another look. > As said in the comment 45, I > don't think the conflict with "saves actions" should be addressed in this > initial version. A lot of developers use save actions and if you look at the project settings of our Eclipse projects, they have them enabled at the project level. There would have to be a big warning that enabling auto-save interferes with this, and as a result most developers will probably not use the auto-save feature. > About this new version, I introduced a new event Last_Modified to let users > know that a part has been modified. How do you let the user know? The change in AbstractTextEditor indicates (didn't do a full review of the Platform UI changes) that you are restricting the feature to specific editors now, or, expect other editors to do something in order to get the feature. In that sense I liked the previous version better.
(In reply to Dani Megert from comment #53) > > > About this new version, I introduced a new event Last_Modified to let users > > know that a part has been modified. > > How do you let the user know? The change in AbstractTextEditor indicates > (didn't do a full review of the Platform UI changes) that you are > restricting the feature to specific editors now, or, expect other editors to > do something in order to get the feature. In that sense I liked the previous > version better. It is the only I found to be notified for editors changes. In the previous version of the contribution, the SaveAllDirtyPartsAddon class had an IEventBroker that subscribed to UIEvents.Dirtyable.TOPIC_DIRTY, but this is not the right event to subscribe, because when an editor is already dirty, then a change in this editor will not send another dirty event. With this new version, the IEventBroker subsribes now to UIEvents.Dirtyable.TOPIC_LAST_MODIFIED, an event that is send when a change occurs in an editor, not only when an editor switch to the dirty state.
(In reply to Axel RICHARD from comment #54) > (In reply to Dani Megert from comment #53) > > > > > About this new version, I introduced a new event Last_Modified to let users > > > know that a part has been modified. > > > > How do you let the user know? The change in AbstractTextEditor indicates > > (didn't do a full review of the Platform UI changes) that you are > > restricting the feature to specific editors now, or, expect other editors to > > do something in order to get the feature. In that sense I liked the previous > > version better. > > It is the only I found to be notified for editors changes. In the previous > version of the contribution, the SaveAllDirtyPartsAddon class had an > IEventBroker that subscribed to UIEvents.Dirtyable.TOPIC_DIRTY, but this is > not the right event to subscribe, because when an editor is already dirty, > then a change in this editor will not send another dirty event. > With this new version, the IEventBroker subsribes now to > UIEvents.Dirtyable.TOPIC_LAST_MODIFIED, an event that is send when a change > occurs in an editor, not only when an editor switch to the dirty state. I got that, but it really restricts where the feature will work. You should try to apply the timeout to the idle UI.
(In reply to Dani Megert from comment #53) > (In reply to Axel RICHARD from comment #51) > > It takes the comments into account, except the one about the termination of > > existing actions (e.g. content assist...). > > Sorry, but this is a no go. Let me know when you have something that doesn't > interrupt those, and I will take another look. I understand that you want a fully functional feature for the auto-save, that handles all interactions with eclipse. Except for that part, I think the contributions I pushed on gerrit do the job correctly. As Mikael proposed in the comment 45, I could add warning notice about this disturbing behavior should be displayed on the preference page. As a first step I would really need your review and comments on the current design as I assume specifically handling the content assist is not challenging the approach (but tell me if you think it is). Right now I have no idea if I'll have enough bandwith to consider handling it as part of this work, any pointer on this specific issue would be really appreciated. Then, the community will be able to handle the termination of existing actions like the content assist, based on the contributions I made. In the new version of the contribution, yes, the editors have to send the new event but we implemented in the abstract editors like AbstractTextEditor and FormEditor. So the huge part of editors won’t have to do anything to get the auto-save. So far that's the only way I found to handle the auto-save with a countdown which gets re-initialized when the user interacts within the editor. As an alternative solution, in the comment 55, you said that I should try to apply the timeout to the idle UI. Could you please elaborate on this comment ? Would that be an alternative solution for the countdown ? Thank you Best Regards,
(In reply to Axel RICHARD from comment #56) > As a first step I would really need your review and comments on the current > design as I assume specifically handling the content assist is not > challenging the approach (but tell me if you think it is). Taking down content assist or any other shell is a no go as it interrupts the user's workflow. > Right now I have > no idea if I'll have enough bandwith to consider handling it as part of this > work, any pointer on this specific issue would be really appreciated. One way would be to only save when the editor (shell) itself has the focus. Drawback is that it won't save while any other shell is open. But that is far less an issue than interrupting the user's workflow. Another way would be to save when the editor part is no longer the active part. That would avoid interfering with typing and also make the Save Action problem a bit less an issue. Additionally, one could consider to save when the focus is lost, but the tricky part is to only do this when a "main" window/shell becomes focus, otherwise one runs into the original shell lost problem. This solution would also get rid of any code that needs to figure out inactivity to trigger the save. > Then, > the community will be able to handle the termination of existing actions > like the content assist, based on the contributions I made. I don't exactly understand what you mean. > As an alternative solution, in the comment 55, you said that I should try to > apply the timeout to the idle UI. > Could you please elaborate on this comment ? Would that be an alternative > solution for the countdown ? Yes, instead of relying on modification events, try to figure out whether the IDE is idle for a certain time. org.eclipse.ui.internal.ide.application.IDEIdleHelper does something like that to decide when to do a GC.
(In reply to Dani Megert from comment #57) Dani, Thank you very much for your answers. Here is what I propose: - Way 1 : I revert to the first version of the existing contribution and do what you propose in the comment 57: « One way would be to only save when the editor (shell) itself has the focus. Drawback is that it won't save while any other shell is open. But that is far less an issue than interrupting the user's workflow. » So, the countdown will not be reset on user activity, but the content assist will not be close anymore on auto-save. I will also add a notice in the preference page to warn users that the save actions (auto-format…) could be problematic when the auto-save is enabled. - Way 2 : I create a new contribution and try the org.eclipse.ui.internal.ide.application.IDEIdleHelper way. The countdown will be reset on user activity, and the content assist will not be close anymore on auto-save if I also apply your proposition: « One way would be to only save when the editor (shell) itself has the focus ». I will also add a notice in the preference page to warn users that the save actions (auto-format…) could be problematic when the auto-save is enabled. To everybody, What do you think about these propositions ? Which one seems the best according to you ? Best Regards, Axel
(In reply to Axel RICHARD from comment #58) > (In reply to Dani Megert from comment #57) > > Dani, > > Thank you very much for your answers. > > Here is what I propose: > - Way 1 : I revert to the first version of the existing contribution and do ... > - Way 2 : I create a new contribution and try the ... With way 1 you really need to add some means to reset the timer. For example you could reset it whenever you get an SWT.Modify event (hint: see Display#addFilter). Drawback: it will also reset when the user types some text into a text field anywhere in the IDE. The benefit of way 1 is that you can faster deliver a new version of the change which fixes the shell issue. If the inactivity code doesn't work well, you can still move to way 2.
Hi, I just pushed a new version of the contribution that takes into account the last comments from our discussions. Do not hesitate to review and comment this new version of the contribution. Thanks in advance. Best Regards, Axel
I've given a try to your latest patch. It works well and is much less intrusive than the previous one. It does not interrupt any code completion, hover, etc. However, now that the timer is reset at each click, I have the feeling that the default timer value should be shorter than 60sec. I rarely do nothing in my IDE window for 60sec. Such a long timer makes the auto-save useless. IMHO, a good default would be something from 15 to 20sec. I will make some comments about the code directly in the review.
After trying it a bit more, it happens that it does not handle the multiple workbench windows well. Step to reproduce: 1/ open a new workbench window (Windows > New Window) 2/ Edit some files in the new window 3/ Come back to the first windows and edit other files in there. 4/ Wait for the auto-save to be triggered Only the first windows editors are saved.
(In reply to Mikael Barbero from comment #62) > After trying it a bit more, it happens that it does not handle the multiple > workbench windows well. Step to reproduce: > > 1/ open a new workbench window (Windows > New Window) > 2/ Edit some files in the new window > 3/ Come back to the first windows and edit other files in there. > 4/ Wait for the auto-save to be triggered > > Only the first windows editors are saved. Mikaël, The last version of the contribution should solved the problem. Best Regards,
There is still a new issue now: you are adding a lot of idleListener (basically each time a dirty event is triggered). I will submit a change to your review shortly but I'm afraid we're out of time for M6...
(In reply to Mikael Barbero from comment #64) > There is still a new issue now: you are adding a lot of idleListener > (basically each time a dirty event is triggered). I will submit a change to > your review shortly but I'm afraid we're out of time for M6... I've fixed the issue and done some cleanup in the SaveAllDirtyPartsAddon (see https://git.eclipse.org/r/#/c/66742/4..5/bundles/org.eclipse.ui.ide/src/org/eclipse/ui/internal/ide/addons/SaveAllDirtyPartsAddon.java). Please review and test ASAP. I think that, with this last change, we're good to go for a formal review from the Platform UI committers. Does any of you think it could still be done before M6? It would be so great to have this feature in Neon. Thanks a lot.
(In reply to Mikael Barbero from comment #65) > (In reply to Mikael Barbero from comment #64) > > There is still a new issue now: you are adding a lot of idleListener > > (basically each time a dirty event is triggered). I will submit a change to > > your review shortly but I'm afraid we're out of time for M6... > > I've fixed the issue and done some cleanup in the SaveAllDirtyPartsAddon > (see > https://git.eclipse.org/r/#/c/66742/4..5/bundles/org.eclipse.ui.ide/src/org/ > eclipse/ui/internal/ide/addons/SaveAllDirtyPartsAddon.java). Please review > and test ASAP. > > I think that, with this last change, we're good to go for a formal review > from the Platform UI committers. Does any of you think it could still be > done before M6? It would be so great to have this feature in Neon. Thanks a > lot. Mikaël, With your last modifications from https://git.eclipse.org/r/#/c/66742/6, the issue you described in comment 64 is gone, and it still works very well. Thank you very much. Best Regards,
Dani, as your concerns have been addressed, could you please review the latest change set? Thanks.
(In reply to Mikaël Barbero from comment #67) > Dani, as your concerns have been addressed, could you please review the > latest change set? Thanks. Looks good. I would like to commit this today, so that we can include it in our test pass tomorrow. Axel or Mikael, are you able to address my comments today?
(In reply to Dani Megert from comment #68) > (In reply to Mikaël Barbero from comment #67) > > Dani, as your concerns have been addressed, could you please review the > > latest change set? Thanks. > > Looks good. I would like to commit this today, so that we can include it in > our test pass tomorrow. > > Axel or Mikael, are you able to address my comments today? Thanks Dani. I will address you comments today.
Any plans for further improvements in the UI side of things, such as: * Automatically saving the editor if the user clicks on the close button/action (without asking for confirmation). * Not showing the dirty mark on an editor if auto-save is on. ? Or would this be left for a future iteration?
(In reply to Bruno Medeiros from comment #70) > Any plans for further improvements in the UI side of things, such as: > * Automatically saving the editor if the user clicks on the close > button/action (without asking for confirmation). > * Not showing the dirty mark on an editor if auto-save is on. > ? > Or would this be left for a future iteration? Yes, new feature requests.
I've updated the change set. Sorry for the delay
Gerrit change https://git.eclipse.org/r/66742 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b89221479f198596184c480b1497989ad7d43b83
Remaining and new issues will be handled by new bug reports.
Axel/ Mikael can you this to the N&N for M7
(In reply to Dani Megert from comment #74) > Remaining and new issues will be handled by new bug reports. Created: https://bugs.eclipse.org/bugs/show_bug.cgi?id=492454
*** Bug 34076 has been marked as a duplicate of this bug. ***
(In reply to Lars Vogel from comment #75) > Axel/ Mikael can you this to the N&N for M7 Lars, here is the gerrit review for the N&N : https://git.eclipse.org/r/#/c/71458/
BTW, I think this phrase on the preferences page is a bit weird: "the Save Actions from editors may cause a disturbing behavior." It's not very clear for a normal user what that means. But more than that, it doesn't seem written in good English. It probably should be "may cause disturbing behavior", or even better: "may cause erratic behavior". Maybe it's just me, but when I hear "disturbing behavior" I usually associate that idiom with violence or gore, similar to when news casters say the expression "The following pictures may be disturbing to some viewers".
