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

Restore autosave ? #335

Closed
Carreau opened this issue Jul 12, 2016 · 7 comments · Fixed by #618
Closed

Restore autosave ? #335

Carreau opened this issue Jul 12, 2016 · 7 comments · Fixed by #618
Assignees
Labels
question status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@Carreau
Copy link
Contributor

Carreau commented Jul 12, 2016

The fact the jupyterlab does have the ability to prevent closing phosphor tabs and save notebook is great, though other things can happen like network connection down... etc, and a few time I've close JupyterLab withhout saving, with habit of normal notebook.

Can we re-enable, or speedup the delay between autosave?

@Carreau Carreau modified the milestone: 0.90 Jul 12, 2016
@blink1073
Copy link
Member

Spit-balling: We should create checkpoints for all documents from the context manager whenever we save, and have it create checkpoints for all open files periodically. When we load a file, check for a checkpoint before getting the disk contents.

@blink1073
Copy link
Member

Okay, I had misinterpreted what a checkpoint is. They were created only when created explicitly saving. The file itself is auto-saved (but only notebooks previously). I am going to bring this up at the meeting today.

I propose that we emulate what a desktop editor would do: aggressively save to a temporary file that can be recovered, and have a setting for an auto save interval to disk. "Checkpointing" should be done using version control. We should also periodically check for a file change on disk and ask to revert.

@minrk
Copy link
Contributor

minrk commented Jul 26, 2016

The current behavior, modeled on modern applications and the norm for web applications, was picked specifically as opposed to the behavior of apps like word and emacs, which necessitates unpleasant things like recovery dialogs, timestamp comparisons etc., the triggers for which are all much more likely to happen in a browser app than a regular desktop application.

With server-side document state, I don't think we would need necessarily need autosave anymore, because the browser is no longer the sole home for unsaved state.

@blink1073
Copy link
Member

Message received :). I'll follow the IPEP.

@Carreau
Copy link
Contributor Author

Carreau commented Jul 26, 2016

Note that the IPEP apply to the notebook only, but I think consistency is important. I thought agree that is is less than optimal, and agree that a server-side state would be much better.

@Carreau
Copy link
Contributor Author

Carreau commented Aug 3, 2016

Bumping that please, I again lost 30 min of work because of a new "go to previous page" chrome shortcut [Ctrl+LeftArrow]

@blink1073
Copy link
Member

Yep, this is first on my list when I get back. Also note you can disable that behavior on OSX at least.

@lock lock bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Aug 11, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Aug 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants