Bugzilla – Full Text Bug Listing
| Summary: | Canceling save actions re-saves the file without asking | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Didier Loiseau <didierloiseau+eclipse> |
| Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | daniel_megert |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Didier Loiseau
This is by design, so that you can quickly undo the save actions but still be in a 'saved' state. It also serves as safety net in case one of the save actions destroys the file. This won't change. Isn't this the purpose of the "Restore from Local History…" feature? The problem is that you perform a file modification that might not be clearly visible, without any kind of confirmation. You could do this by mistake without noticing. Also going from a saved state to a saved state by performing undo/redo operations on a single file seems quite odd and unusual. Note that Bug 337298 suggests to have a "Save without save actions" feature. If it was available, this bug could be fixed easily by marking the editor as dirty after the undo (like when you undo after save in all other cases) which would allow the user to confirm that he really wants to save without save actions. (In reply to comment #2) > Isn't this the purpose of the "Restore from Local History…" feature? Well, that's the whole point. The local history only contains saved state. (In reply to comment #3) > (In reply to comment #2) > > Isn't this the purpose of the "Restore from Local History…" feature? > Well, that's the whole point. The local history only contains saved state. So this proves that it is not necessary to save the file without confirmation after you undo the save actions… This is the same as if I modify a simple file (without save actions): 1. The file is in a saved state 2. I do some modifications 3. I save the file 4. I perform and "Undo" 5. The editor is in the same state as in 1 but the editor is marked as dirty As said, save must be a "safe" operation and what you see in the editor at the point you save must be on disk. In addition you need to have a quick way to revert the auto-save modifications. If that revert operations makes the editor dirty again (as in a normal editor without save actions), then you can never put it on disk unless you use a different command as proposes by bug 337298. (In reply to comment #5) > As said, save must be a "safe" operation and what you see in the editor at the > point you save must be on disk. I totally agree with that: it must appear in the local history. > In addition you need to have a quick way to revert the auto-save modifications. I don't understand why you would need that, this should not be an usual/easy operation. > If that revert operations makes the editor > dirty again (as in a normal editor without save actions), then you can never > put it on disk unless you use a different command as proposes by bug 337298. Or you can use the "Replace With > Local History…" feature, which allows you to revert the save actions modifications, and thus recover your file if they have destroyed it. This should rarely be necessary since save actions are enough stable, I think. The only other reason to have this "feature" is thus as an easy (and unusual) workaround for Bug 337298. >I totally agree with that: it must appear in the local history. Right, and hence 'undo' must not ignore that entry. > I don't understand why you would need that, this should not be an usual/easy > operation. Yes, exactly - it should be easy. And it is not unusual: I often need it e.g. because I don't want the auto-formatting when working in another project which I'm not the owner (and which hasn't project specific settings). > The only other reason to have this "feature" is thus as an easy (and unusual) > workaround for Bug 337298. People should not have to remember two different save commands and most of the time you only notice after saving that you don't want the auto save changes. Which means you are forced to invoke two commands instead of just one. (In reply to comment #7) > > I don't understand why you would need that, this should not be an usual/easy > > operation. > Yes, exactly - it should be easy. And it is not unusual: I often need it e.g. > because I don't want the auto-formatting when working in another project which > I'm not the owner (and which hasn't project specific settings). What prevents you from creating project specific settings then? Of course you will have to take care not to commit them, but this would be another issue… > > The only other reason to have this "feature" is thus as an easy (and unusual) > > workaround for Bug 337298. > People should not have to remember two different save commands and most of the > time you only notice after saving that you don't want the auto save changes. > Which means you are forced to invoke two commands instead of just one. Your solution is already to invoke two commands instead of just one: save and then undo. People who often use this technique should wonder why they have configured save actions in the first place… |