GNOME Bugzilla – Bug 682977
Save drafts of all edited work
Last modified: 2020-11-24 09:57:16 UTC
The current model that we, and most traditional file editors, use has a number of problems with respect to how work is saved. No data is written to disk until the user explicitly attempts to save the work, picks a filename, and location. The effect of this is that we lose all of the work if the app crashes, if the OS crashes, or if the machine powers off. This is not the expectation of most users today. We would like our time and effort to be in safe hands. If you are editing a file on a remote/network device and the network drops - you can lose your work. If you are editing a file on a removable device and it is removed - you can lose your work. And so on. So, I propose that we adopt a model that is known to work. Gmail. Something like this: * Any time you have entered information we save a draft (possibly somewhere like ~/.config/gedit/drafts). * When you explicitly place your work somewhere (the save/name/place operation) we move the content there. And the drafts is empty. * If the app starts and there is content in the drafts folder it should alert the user and allow resuming or discarding. * The app should no longer block logout or shutdown because drafts are safely stored. * If the app is explicitly quit the user may be prompted to save the drafts or remove them. * The first time the user asks to place the file somewhere we can make an intelligent suggestion for the name / title of the file based on the contents of the file. * We can continue to monitor the original file for changes and notify the user if the network is unavailable or if the original content has changed.
Sorry I meant ~/.cache/gedit/drafts
" * Any time you have entered information we save a draft (possibly somewhere like ~/.config/gedit/drafts)." This should stay true, i think, even after the user has saved and given the file a name. I.e., the draft is always a back up of the source view buffer, not just a staging area before the file is "realized" with a name (You may have meant this already, not sure). Furthermore, we should never autosave to the file name, only to cache file (also above you say ~/.config but i think you mean ~/.cache) " * If the app starts and there is content in the drafts folder it should alert the user and allow resuming or discarding." Maybe it would be better to just open from the cache non-interactively, and if they want to discard they can close it explicitly? " * If the app is explicitly quit the user may be prompted to save the drafts or remove them." I'd argue it would be better to just save it implicitly too. If the user wants to discard the draft, they can just close the draft itself (the X in the tab), and not the app. Thoughts? Why ask the user what to do, when we could just let the user do what they want just as easily? We could make the caches entirely implicit.
(mid-air collision between comment 1 and comment 2)
Some notes from the irc discussion (mostly for myself and the gedit team) 1) I generally like this plan (as opposed to other form of autosaving for which gedit is not really suited) 2) I really like the idea of dropping our shutdown stuff which I hate 3) We may need to fallback to the old strategy in some cases (e.g. filled quota in home), which I think is ok since the proposed user experience is consistent with the current behavior, just improved 4) We will need to check all the usual miriad of headaches and corner cases (e.g. truncate and rewrite when permissions cannot be set etc etc) > * The first time the user asks to place the file somewhere we can make an > intelligent suggestion for the name / title of the file based on the contents > of the file. This part is unrelated and actually it was discussed many times also with gnome 2 designers... We always failed to figure out a good enough heuristic (e.g. you could end up always suggesting a name which is the first line of the GPL or the doctype of an xml doc etc. > * We can continue to monitor the original file for changes and notify the user > if the network is unavailable or if the original content has changed. This is also unrelated, but it is a good idea... we already monitor local files to check changes with stat(), we could extend it for remote files to check if at least the network is available
(In reply to comment #2) > " * If the app starts and there is content in the drafts folder it should alert > the user and allow resuming or discarding." > Maybe it would be better to just open from the cache non-interactively, and if > they want to discard they can close it explicitly? > We can open the file and show an info bar, no need for a blocking "do you want to restore" dialog > " * If the app is explicitly quit the user may be prompted to save the drafts > or > remove them." > I'd argue it would be better to just save it implicitly too. If the user wants > to discard the draft, they can just close the draft itself (the X in the tab), > and not the app. Thoughts? > > Why ask the user what to do, when we could just let the user do what they want > just as easily? We could make the caches entirely implicit. Well I think there are a couple of reasons to warn: *) first an most important, you close forgetting to save and then you send an incomplete file attached to a mail: we should warn the user that foo.txt does not contain his latest changes even if they are saved "somewhere" *) there is a potential privacy issue that if the user did not save the latest changes, closes gedit and then removes foo.txt, he still has a copy saved behind is back with the potentially sensitive content
(In reply to comment #5) > > Maybe it would be better to just open from the cache non-interactively, and if > > they want to discard they can close it explicitly? > > > > We can open the file and show an info bar, no need for a blocking "do you want > to restore" dialog Sounds fine, as long as the info bar is "Document restored from drafts [Discard] [Cool]" and not "Unfinished documents in drafts [Discard] [Load]" > Well I think there are a couple of reasons to warn: > > *) first an most important, you close forgetting to save and then you send an > incomplete file attached to a mail: we should warn the user that foo.txt does > not contain his latest changes even if they are saved "somewhere" Maybe we should have some standardized way of linking a draft to a document, so at attach time the mail client can inform the user the document is still in progress (might be hard for gmail) > *) there is a potential privacy issue that if the user did not save the latest > changes, closes gedit and then removes foo.txt, he still has a copy saved > behind is back with the potentially sensitive content Maybe we should warn a user when they delete a file that has an unsaved changes (might be hard for /bin/rm)
We have to do similar feature to SublimeText's one. Keep all documents in a session. In the session we don't have to save, recover any documents. It doesn't require close button to show any warning dialogue while quite. Moreover, we can place Save button from toolbar/headerbar to menu as rare usage. By the way, the bug 653687 is probably duplicate.
*** Bug 710903 has been marked as a duplicate of this bug. ***
Thanks for your insight, Paolo (from ticket 710903). It amazing that my proposal is almost identical to the original (original + feedback = mine). I'd be happy to make the changes. I just wanted to have agreement from at least one of the "gedit" developers that it was a good/reasonable idea. It looks like this is unanimous, from the comments on the original ticket. I also wanted some direction, as I'm not familiar with: 1) the flow when it comes to how unsaved documents vs. saved documents are represented in the application, and 2) how "saving" is initiated, how unsaved documents are skipped, and whether "saves" are performed sequentially through the documents or asynchronously on every document (potentially in parallel). If you (or anyone) is open to answering the above questions, I could also use references to actual functions and filenames, if that's not too much of a burden. Otherwise, I could [try to] figure this out myself.
I went another way and wrote a plugin for this: https://github.com/dsoprea/GeditSafetySave . It should be Python 2.x/3.x compatible (no affected functionality was touched, unless there was something specific to PyGTK that I was unaware of). Take a look. See if there are any obvious improvements that can be made (with a practical amount of effort for its gain). I'd like this plugin to be considered for bundling with gEdit. Everyone could benefit from it. From the README: ==================== Once this plugin is installed and enabled (within the plugin listing, in gEdit), all unsaved documents will begin to be watched. When an unsaved document is saved by the user, its file in temporary storage will be deleted. If all unsaved documents are saved by the user and all temporary files are removed, the storage directory will be removed. All old temporary files will be periodically cleaned-up (currently, every four weeks). Your unsaved documents will be stored under a directory named after the date/time that your gEdit session was started. For example: ~/.gedit-unsaved/20131027-052807/Untitled Document 1 Lastly, this plugin will observe your "autosave" setting. If "autosave" is disabled, this plugin will not do anything. Otherwise, your unsaved documents will be stored at the same frequency. In other words, if your "autosave" is configured for two-minutes, this is the frequency at which your unsaved documents will be stored. ====================
This plugin is solid. I would appreciate some feedback or corroboration that it satisfies the requirement. Then, we can close this bug.
I don't think the plugin is a way to go. It must be in core codebase. Autosave doesn't prevent all data loss, because of some intervals between each autosave actions. Why don't keep it in session as I mentioned in comment 7?
I had trouble understanding that comment. By "session", do you mean that all previous tabs are recovered when the gedit is opened? Whether native or via plugin, isn't the strategy still going to be the same?: For all unnamed documents (similar, but not identical to method for named documents): 1) Spawn a "save" thread at the app level, loop while waiting on the "update queue" to be non-empty. 2) Keypress signal received and filtered for only change-affecting keys. 3) Insert document into the "save" thread's update queue. 4) "save" thread activates, dequeues one document to save, initiates save. 5) "save" thread comes-down on deactivation, saves all queued documents prior. The thread is at the application-level because the system caret (user) can only work on one document at a time. I wouldn't mind working on a change to the native code, but it still doesn't seem like it's necessary, and there will be a "dependency" cost, in that I'll need direction from other people on this list on how to proceed (again, since I'm not initiated to the strategies of the parts of gedit that I'll be affecting). Thoughts?
Please have a look at apps like SublimeText or Firefox to understand how it must work: when you close session or something went wrong, after new start you will get the same tabs/documents/whatever without any changes. Those apps don't require any plugins. I consider it's good design and great UX: user shouldn't care about the fact whether she saved the document or not. I'm not sure what the algorithm is the best in that case, but my guess is "save per any change" is better that looping. Let's wait for Paolo Borelli's respond, he must know the point as core developer.
Bump (Paolo).
Sorry, I was abroad the whole week with limited connection and I am still trying to catch up so I just skimmed through this and I did not have time yet to look at the plugin code. I think in the long run this should be done in the core and work out of the box, but at the same time the fact that Dustin managed to do it with a plugin is pretty cool and also gives us an interim solution that can be used today while we take the time to do it properly in the core.
Created attachment 346697 [details] User case (in 2017) Seems like this is still causing people some headaches.
I would also love this feature to be there. I just migrated from Mac and its basic TextEdit does save all drafts automatically. I would add that beyond saving all drafts it would also be great to restore the previous session. So all windows which were previously opened, with all drafts as well.
I just lost work in multiple files after a system crash. So count me in for a vote on a feature like this as well.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.