ci_edit icon indicating copy to clipboard operation
ci_edit copied to clipboard

Save temporary file in case of unexpected exit.

Open aaxu opened this issue 7 years ago • 3 comments

Not sure if it is possible to efficiently keep a saved state of the current modified file in case of an unexpected exit (shutdown, restart, terminal closed). Maybe it would be possible to detect the signal that the terminal sends this program and gracefully save the state. Will have to look more into this later. When the user opens the file again, we can ask them if they want to keep the changes or not.

aaxu avatar Nov 28 '17 19:11 aaxu

Maybe (brainstorming) we can use the saved redo. We could write the redo to disk more often. And make the hash/sha match the saved version of the file. So that if there is an unexpected exit, the hash will match and the redo will still be there.

We could further write a flag with the saved redo (or somewhere in .ci_edit/...) while the file is being edited -- saying that the file did not close properly. When the file does save properly, we'd clear the flag.

Later when a file is opened again and the flag is set (and there is redo available) we can prompt the user about restoring the edits they were working on.

dschuyler avatar Nov 29 '17 18:11 dschuyler

Maybe (brainstorming) we can use the saved redo. We could write the redo to disk more often. And make the hash/sha match the saved version of the file. So that if there is an unexpected exit, the hash will match and the redo will still be there.

I think we'll run into a problem with this approach if the user rewrites the redo chain history (undo, truncate, and makes new changes). If this rewriting goes to before the current redo index of the old saved file, then we would miss all previous redos. This might be fine if we were to implement the redo tree, so that we could then just keep a pointer at some previous state and trace back if we want to revert to an old state.

Also, if a person were to completely write a large file without saving (living dangerously), then a long redo chain would cause a lot of processing to occur. Maybe it would be worth it to occasionally save the entire file instead. We could speed this up by pickling or compressing the file if speed/size is an issue.

aaxu avatar Nov 29 '17 18:11 aaxu

Just brainstorming as well, but maybe it would be possible to break up a tree into different sections. Upon hitting a certain number of unsaved redos, we could break off this section of the tree and save it as a temporary file. The parent of this broken section should have a reference to this temporary file so that when recovering from an unexpected exit, we could rebuild the tree from multiple temporary files.

aaxu avatar Jan 11 '18 18:01 aaxu