GNOME Bugzilla – Bug 335079
autosave improvements
Last modified: 2020-11-24 09:56:59 UTC
I would like to turn autosave into a preference that makes the task of saving completely transparent to the user. The easiest and least "dangerous" method probably is to save the document everytime it is closed or the focus leaves the window. This way saving operations are unlikely to disturb the user while editing, but the document is still up to date whenever the user might want to access it from a different application (like a web browser or compiler). Rational: Manual saving is a task that mainly results from (historical) technical requirements instead of usability requirements. While some users certainly have incorporated it into their workflow, I strongly believe that a user should not be forced to deal with it when it can be avoided. Implementing a realiable autosave mechanism would at least offer the following conveniences to a user: - No necessity to hit CTRL+S after every little change. No chance to forget about it and getting all puzzled when a change has no effect... - No annoying save confirmation dialogs (unless the user has untitled documents, which can be avoided). - No necessity to understand the abstract nature of a text buffer in memory as opposed to the actual text document on disk. For the user, the displayed text becomes the document. - Reduced chance of data loss. Other information:
Created attachment 61523 [details] [review] first version of the patch This patch activates autosaves everytime the focus leaves the window. Additionally titled documents are automatically saved on a close request. Both only when the autosave option is set of course. It does not deal with session management yet, but that should be straight forward to add. It also activates everytime the focus switches to a gedit dialog (including the save confirmation dialog), I don't know if and how this can be avoided. I will use this for a while and see how it goes.
The patch looks good from a really quick glance[*] While not an autosave user myself, it makes sense to me to turn the autosave feature in a buffer-on-screen==file-on-disc mode. In fact I would probably take the chance to also remove the 'N minutes' preference from the UI, since it's exposing an implementation detail and I doubt anyone has any good reason to tweak that except us turning it to the min when we testing autosave :) The general issue to discuss are: a - we should probably special case the remote files somehow, since saving remotely it's slow and at the moment it blocks editing the file. Autosaving on remote files may also have other issues (think of editing a website and broken changes go live while editing), but I guess these fall in they "Hey, you turned autosave on yourself, what do you want from us? a mind reading editor?" field :) b - how does this impact the current autosave users? Are there good reasons why one may have wanted the current autosave behavior enebled but not the new behavior? [*] very minor observation, you left in the bacon-message-connection hack and there are some unneeded whitespace changes.
(In reply to comment #0) > Rational: Manual saving is a task that mainly results from (historical) > technical requirements instead of usability requirements. While some users > certainly have incorporated it into their workflow, I strongly believe that a > user should not be forced to deal with it when it can be avoided. Definitely. However, there are some issues: * Some system files should not be saved in intermediate states, no? You only want to save it when you are certain it is correct. Auto-saving to the actual file location might break things, and gedit is meant to be a system file editor. * If a file is temporarily changed in a way that destroys information, autosaved, and then accidentally closed, that information is lost forever. A revision control system (like a wiki has) would prevent this loss of data, but would likely require some interface changes. Scribes (http://scribes.sourceforge.net/) has permanent autosave as you describe, without any revision control, and I don't trust it. In the future, I imagine the concepts of save/open/undo/redo/revision control/collaborative changes/application close/application minimize and so on all being recombined into a single glorious new editing paradigm that won't require any conscious maintenance and will never lose data. :-) I've started writing an essay about it, but haven't finished. But to implement parts of this vision without implementing others (like autosave without revision control) would be bad. So, in the meantime, we kind of have to compromise with the "historical" paradigm. So I'm thinking along the lines of expanding the "backup" functionality into something better, so that it autosaves revision diffs to a separate file as you type (analogous to the way an auto-backup is saved in "file.txt~"), allowing you to re-open the document as you last had it, and use undo or redo to go back to previous versions if they were not what you actually wanted it to save when it crashed. When you are sure of a version, you press the Save button (more like "Commit" in this case), and it is saved to the original "file.txt" location.
(In reply to comment #2) > In fact I would probably take the chance to also remove the 'N minutes' > preference from the UI, since it's exposing an implementation detail and I > doubt anyone has any good reason to tweak that except us turning it to the min > when we testing autosave :) Definitely. It should not be based on minutes, but on whether the user has the window focused or not, is typing or not, where the file is stored and the amount of resources it takes to save it, etc.
This is very much needed. There should be a number of hidden save files in the file's directory, and Gedit should be tuned to save only changes. This would bi easier with versioning file systems like Ext3Cow, NILFS, ZFS, or the fl-cow library. Perhaps Gedit should test the file system it is working on for versioning. Unlimited, persistent, multi-document undo/redo was explored in Jef Raskin's "The Humane Interface" and implemented in [http://rchi.raskincenter.org/index.php?title=Home Archy]. It is remembered even after a document is closed. Even stronger versioning is explored in Xanadu, [http://xanadu.com/zigzag/fw99/XUmodel.html Floating world] etc. Among other things, it allows all versions of all users to exist permanently and portions of a version to be referred to in a document, precise down to characters.
(In reply to comment #5) > Unlimited, persistent, multi-document undo/redo was explored in Jef Raskin's > "The Humane Interface" and implemented in > [http://rchi.raskincenter.org/index.php?title=Home Archy]. It is remembered > even after a document is closed. > > Even stronger versioning is explored in Xanadu, > [http://xanadu.com/zigzag/fw99/XUmodel.html Floating world] etc. Among other > things, it allows all versions of all users to exist permanently and portions > of a version to be referred to in a document, precise down to characters. I haven't seen those, but I've had similar ideas on the subject, as in my earlier posts. I just finished up what I was writing and published it here: http://endolith.com/wordpress/2007/12/24/abolish-the-saving-of-documents/
(In reply to comment #3) > Scribes...has permanent autosave as you describe, > without any revision control, and I don't trust it. I agree. From what I've read of the feature, I don't think it has the correct model. > But to implement parts of this vision without implementing others (like > autosave without revision control) would be bad. I don't think revision control is a necessity. In contrast, preventing data loss from a crash really should be considered a basic core feature of any modern desktop application. (Such a feature used to have significant performance impact, and thus it was omitted, and users became accustom to this. These days a typical web browser has more crash resilience than most text editors.) (I think Gedit partially meets this requirement currently: It doesn't save unnamed buffers (Bug #485471), and it lacks awareness that a crash has happened previously, and makes no attempt to restore previously opened files.) > ...I'm thinking along the lines of expanding the "backup" functionality into > something better, so that it autosaves revision diffs to a separate file as > you type, allowing you to re-open the document as you last had it, and use > undo or redo to go back to previous versions if they were not what you > actually wanted it to save when it crashed. When you are sure of a version, > you press the Save button (more like "Commit" in this case), and it is saved > to the original "file.txt" location. Treating Save like commit is correct, and much better than the current behavior of autosave overwriting the original location, but the rest is more complicated than necessary. Here are the characteristics of an autosave feature, which I've seen implemented successfully in other editors: 1. Automatic saves are performed periodically, if the file has changed, and stored to a file separate from the original file. (Unnamed buffers also need to be saved. See Bug #485471.) 2. The temporary storage area is in a user configured location on the local disk, and thus avoids the performance hit when editing network files. 3. When the user manually saves the file, the changes are committed to the original location, and the temporary file removed. In addition... 4. The editor should track the list of open documents (and their corresponding autosave files), periodically autosaving it, so when restarting after a crash, prior documents can be reloaded, and uncommitted modifications restored. (There will need to be some logic to deal with the case where the original file is newer than the autosave file.) Saving only diffs instead of a full copy of changes would be nice, but is a performance optimization. (More relevant if you are storing multiple revisions.) A general Gedit optimization to rewrite only the changed portions of a text file (to the extent that can be done), would be useful here too to minimize the performance hit when autosaving large files.
Yeah, I'm not talking about preventing data loss from a crash, though. I think that modern document-editing applications should save all revisions of a document automatically. Google's already doing this with Google Docs, for instance. I think it should be a standard feature in any desktop application that modifies files, or maybe part of the OS/filesystem itself. Gedit currently saves one revision for this purpose automatically, but I understand if people don't think a full revision control is part of the goals of Gedit. After Apple does it, though, I bet it suddenly becomes a good idea. ;)
A fairly simple improvement would be to suspend autosaving while the user is typing, for example if there has been a keystroke in the last 3 seconds. Saving is synchronous. In my experience on a relatively slow computer, gedit often discards several keystrokes if it autosaves while I'm typing quickly.
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.