Automatic backups / history feature

[tobimensch]

This is a feature I've come to value from vscode/vscodium.

Of course, you can use something like git to manually check in your changes, however if we're honest, sometimes we'll forget to do it, or we'll be working on files, which aren't inside a git repository.

Also, there's nothing to say against combining two great things, git and automatic backups.

In vscode there's a hidden folder named ".history" that exists in each folder where vscode makes edits. The files inside .history are then named filename_20200311104656.ext

So path/filename.ext is stored in path/.history/filename_DATEANDTIME.ext

Moe would need to provide the following to make this work:

1. Be able to display all the history backups for the current file in a filer like mode. With the most recent one being shown at the top. When you select one of the backups, you should just be able to view it, editing permissions for the backup files should not be allowed, to prevent data corruption. Then you can compare those history files to your current file, and maybe revert something or the whole file.
2. Automatic backups should be made every X minutes from the current buffer (not what's on the disk!), which should be configurable. A backup only needs to be initiated if there's a difference between the last backup file and the current buffer. If there are no changes for 2 hours, a new file should not be created.
3. Backups should be stored for X amount of days, or forever. Personally I'd set the default to forever, because today storage is really cheap and losing data/work is really bad. If one of the .history files is older than X days, it gets removed, the others stay. There's also a setting for this time period in vscode, so maybe we could also provide the option to vscode, meaning use their settings.
4. Do not store those backups in the middle of typing, use idle time instead. In other words, wait for periods of time when the user does nothing. If automatic backups are set to every 5 minutes, it should not be forced to work on minute 5 second 0, rather it should first wait for some idle time, to ensure the users workflow never gets interrupted. So it's better when the backup starts later, for example at minute 5 and 30 seconds, instead of slowing down the editing work of the user.
5. Provide a simple diff viewer that compares the current buffer, to a list of automatic backups, where the latest backup is first in the list.
6. Have exclude settings for where you don't want to produce automatic backups. For example maybe they are not wanted when editing files like /etc/fstab. So /etc/* files (including /etc/*/*) should perhaps be excluded, but the important thing is to that it should be configurable. Personally I'd enable this feature almost everywhere because I can't see much harm in it.
7. When the user has no permissions to create files and or directories in the working file's directory, it should fail gracefully, instead of crashing.
8. Prevent conflicts with vscode. Suppose I have a project open in vscode, but I also edit some of the same files with moe. In that case maybe moe should detect that the most recently written .history files for a buffer were written by a foreign program. This can be easily done by comparing timestamps. If the last .history file was written at a timestamp where moe knows it definitely hasn't done such a thing, I think moe should just assume that backups are currently being written by this other program, and deactivate its own backup writing, until it finds no more backups by this other program. So for example, if it finds out that the backup that was written 3 minutes ago was not written by itself, it would not write a backup itself, and instead wait until the other program hasn't written a backup for at least 20 minutes. I'm not sure if this is the best way to do it, but I wanted to point out that it makes little sense that when both moe and vscode make backups every 5 minutes, that we end up with backups every 2 minutes. There must be a way for moe to yield backups to other programs.
9. Writing to file could additionally also trigger a backup. This would fulfill the condition of not interrupting the users workflow. Note, that it should basically be a copy of the written file, not a backup of the file's old state. This is so because the .history files are supposed to show a progression in the changes to a buffer/file.

Personally I think this feature would be extremely useful.

[fox0430]

@tobimensch

This is a good idea. I will implement in the future.

[tobimensch]

Great!

Let me stress why I think this feature is especially important for an editor that is not yet proven in the eyes of the average person.

Data loss is extremely unfortunate and the worst thing that an editor could do to users is to lose their data. Now, for tried and tested editors like vim, people assume that they won't crash. So they might be comfortable without constant backups there. But when it comes to a v0.2 editor like moe people are wary and they want additional ensurances when it comes to data safety.

This is why I think that with this feature implemented, many users/developers might be more tempted to try moe out and really use it on a daily basis. At least they'd know that they can get a backup every 5 minutes, and the first thing that could happen is for them to lose 5 minutes of work, which is bearable compared to losing half an hour or more.

[fox0430]

@tobimensch

I think so, too. I want to implement a backup system with v0.2.1