Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save temporary file in case of unexpected exit. #116

Open
aaxu opened this issue Nov 28, 2017 · 3 comments
Open

Save temporary file in case of unexpected exit. #116

aaxu opened this issue Nov 28, 2017 · 3 comments

Comments

@aaxu
Copy link
Contributor

aaxu commented Nov 28, 2017

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.

@dschuyler
Copy link
Collaborator

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.

@aaxu
Copy link
Contributor Author

aaxu commented Nov 29, 2017

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
Copy link
Contributor Author

aaxu commented Jan 11, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants