After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 682977 - Save drafts of all edited work
Save drafts of all edited work
Status: RESOLVED OBSOLETE
Product: gedit
Classification: Applications
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 710903 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-08-29 19:18 UTC by William Jon McCann
Modified: 2020-11-24 09:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
User case (in 2017) (629 bytes, text/plain)
2017-02-25 08:49 UTC, Matt Current
Details

Description William Jon McCann 2012-08-29 19:18:43 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.
Comment 1 William Jon McCann 2012-08-29 19:29:15 UTC
Sorry I meant ~/.cache/gedit/drafts
Comment 2 Ray Strode [halfline] 2012-08-29 19:40:44 UTC
" * 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.
Comment 3 Ray Strode [halfline] 2012-08-29 19:41:09 UTC
(mid-air collision between comment 1 and comment 2)
Comment 4 Paolo Borelli 2012-08-29 19:47:07 UTC
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
Comment 5 Paolo Borelli 2012-08-29 19:52:46 UTC
(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
Comment 6 Ray Strode [halfline] 2012-08-29 20:07:57 UTC
(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)
Comment 7 Daniel Korostil 2013-10-19 15:38:26 UTC
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.
Comment 8 Paolo Borelli 2013-10-26 10:47:19 UTC
*** Bug 710903 has been marked as a duplicate of this bug. ***
Comment 9 Dustin Oprea 2013-10-26 17:57:15 UTC
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.
Comment 10 Dustin Oprea 2013-10-27 10:13:59 UTC
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.
====================
Comment 11 Dustin Oprea 2013-10-28 20:42:59 UTC
This plugin is solid. I would appreciate some feedback or corroboration that it satisfies the requirement. Then, we can close this bug.
Comment 12 Daniel Korostil 2013-10-29 10:18:59 UTC
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?
Comment 13 Dustin Oprea 2013-10-29 11:15:10 UTC
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?
Comment 14 Daniel Korostil 2013-10-29 12:12:31 UTC
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.
Comment 15 Dustin Oprea 2013-11-02 06:58:04 UTC
Bump (Paolo).
Comment 16 Paolo Borelli 2013-11-02 10:40:04 UTC
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.
Comment 17 Matt Current 2017-02-25 08:49:01 UTC
Created attachment 346697 [details]
User case (in 2017)

Seems like this is still causing people some headaches.
Comment 18 mmitar 2017-11-27 00:09:09 UTC
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.
Comment 19 Age Bosma (IRC: Forage) 2018-12-02 12:23:36 UTC
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.
Comment 20 Sébastien Wilmet 2020-11-24 09:57:16 UTC
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.