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

multiple-undo for cell deletion #969

Merged
merged 3 commits into from
Feb 6, 2016
Merged

Conversation

minrk
Copy link
Member

@minrk minrk commented Jan 18, 2016

use a stack for undelete_backup instead of a singleton

avoids data loss on multiple undelete

Since this is only for undelete, it's possible for intermediate edits to prevent undeleted cells from going into the exact right place. But it's more important that the cells be recoverable than they be recovered to the exact right place every time.

closes #712

cc @fonnesbeck, who's been patiently waiting for this for ages.

use a stack for undelete_backup instead of a singleton

avoids data loss on multiple undelete
@minrk minrk added this to the 5.0 milestone Jan 18, 2016
@dsblank
Copy link
Member

dsblank commented Jan 18, 2016

+1 Excellent! Is this too extreme to backport into 4.x? The semester hasn't begun yet, so if it happened sooner than later, that would be a semester of happy students and instructors!

@takluyver
Copy link
Member

Nice. This doesn't look too invasive, I think it would be reasonable to put it into a 4.x release.

@fonnesbeck
Copy link

Fantastic, thanks. I will test the heck out of this.

@jdfreder
Copy link
Contributor

Something's not right about the cell ordering, maybe one too many .reverse calls? See the following action shot, where the header and text cells are swapped:

demo

@willingc
Copy link
Member

@minrk I see the same behavior as @jdfreder . It seems to happen when you skip around the notebook and delete cells at the bottom of notebook then top then bottom and then try to undo. It doesn't seem to happen when you delete in order down from 1 to 5. reverse issue seems a likely culprit.

@willingc
Copy link
Member

Hmm... I wonder if I ran into this:

Since this is only for undelete, it's possible for intermediate edits to prevent undeleted cells from going into the exact right place.

I'm pretty sure that at least once I clicked in a cell though didn't change contents.

selects [included,excluded) semi-open range, like Python conventions.
and test multi-cell undelete at both the top and bottom of the notebook
@minrk
Copy link
Member Author

minrk commented Jan 22, 2016

@willingc I think it should be doable to track correctly as long as the only actions are delete/undelete. Once cells are added or moved, that's when I think we can expect it will show up a little funny.

@jdfreder I think I fixed the reversal, and added tests that should cover it.

@jdfreder
Copy link
Contributor

@minrk thanks, I've verified that your change fixes the problem for me.

@jdfreder
Copy link
Contributor

👍 for merge

minrk added a commit that referenced this pull request Feb 6, 2016
multiple-undo for cell deletion
@minrk minrk merged commit 4d64519 into jupyter:master Feb 6, 2016
@minrk minrk deleted the undelete-stack branch February 11, 2016 08:21
@myagmur01
Copy link

I think the easiest way (until developers handle this issue)to retrieve your Ipython history, write them all into an empty file and done! You need to check by the date you created your last script. Obviously, it is going to be the last part of your Ipython history. Good luck!

To write your Ipython history into a file:

%history -g -f anyfilename

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Delete history for multiple undo
7 participants