Delete history for multiple undo

[fonnesbeck]

I created this issue some time ago before the split from IPython, and I assume it now belongs here. While it is easy to quickly delete multiple cells in a notebook, it is currently impossible to undo beyond the last cell deletion. This results in users having to, at best, dig through version control as a remedy, or at worst, suffer data loss. Being able to undo multiple cell deletions would address this.

[lucaswiser]

Totally agree - it is absolutely ridiculous that you can't undo delete more than one cell. The notebook makes it very easy to do this by mistake. Makes it so I can't really use the notebook for any type of serious work.

[fonnesbeck]

@lucaswiser its just a feature request, and its absence anything but ridiculous. I'm not sure that you appreciate how much work has gone into getting the notebook this far.

[markoverholser]

It's your feature request, and he's agreeing that it would be a useful feature, so let's not get carried away taking swings at him. Was the language he used a little bit overzealous? Sure. Did he mean it to be taken as a personal assault on all of the developers and their hard work? I'd hope not, and I'll give him the benefit of the doubt.

I've been lurking for only a few months on this project, mostly for grins and to learn a bit more about team collaboration on code projects, and over the course of that time I've seen the topic of multiple undo come up two, probably three times. In all circumstances, someone on the thread remarked how it's easy to accidentally screw up a notebook to where they can't get it back to where they want it. Since some people use this tool for Serious Work, they will naturally be upset if the tool lets them shoot themselves in the foot and doesn't provide a way to undo the damage. Those people might be prone to hyperbolic language when talking about their experience.

Having multiple undo would be one way to help mitigate the situation. There are more ways than one to skin this cat, though, and perhaps it would also be productive to talk about ways to help prevent the user from damaging their notebooks in the first place. Perhaps add barriers between the user and deleting input cells (individually, successively, or en masse).

What is not productive is snapping at users about how much they should appreciate the work that's already been done. They'll either already appreciate it, or they won't. Dictating to them how much they should appreciate the developers and their work will probably not result in more appreciation. Instead, it is (in my opinion) more likely to result in fewer users, more of whom have a salty taste in their mouth.

For the record, this project is pretty awesome, and I'm amazed at the ongoing development and collaboration I see every day on it.

[lucaswiser]

I get it - lots of hard work making an open source project. No disrespect. The notebook has so many amazing features and is such an impressive tool, it is ridiculous that I can delete some work by pressing d 4 times and it's gone forever (possibly revert to checkpoint and get it back).

[dsblank]

I will also add that having a limited undo capability has made some prominent computer science education researchers comment that Jupyter is not appropriate for any use in the classroom. I disagree, but it does make it a hard sell to some to use Jupyter, and lack of undo/redo causes some real problems with students. At some point, these usability issues will need to be faced by the project and will have to rise to the top of the priorities. There are a lot of possibilities for things to work on, but these basic use limitations should receive more attention. Note, too, that checkpointing has the same kind of limitation: there is only one. Also, it would be at the top of my votes of priorities.

[minrk]

I don't think anyone is snapping or taking swings. We agree this is an important feature and hope to have this ready for the next major release of the notebook. We especially appreciate your patience, since this has taken us so long to get to.

We've been meaning to work multiple undo into a larger undo of notebook transactions, which is part of the source of the delay, but we should be able to get a simpler undelete stack that at least prevents the loss of cells. Even if it might not rigorously put them back where they belong after various add/move operations since the deletion, it should at least prevent data loss, which is the most important part.

[ccordoba12]

Just for the record, it took Wolfram Research 26 years to address multiple undo in the Mathematica notebook! (they did it in Mathematica 10, released just a year and a half ago).

So this is not an easy task at all :-)

[gramster]

A simple approach is to keep an undo stack but clear it on any add/move operations. That probably covers 80% of the use cases while avoiding most of the complexity.

[davidawad]

This just happened to me by accidentally holding down the x key and I don't know to undo it. Please help!

[jiehu567]

And the "cut off" icon is very close to "add" cell. I always accidentally delete my code, omg.

[espoirMur]

it's possible with the shortcut Z in command mode ! for more details check this tutorial: https://www.cheatography.com/weidadeyue/cheat-sheets/jupyter-notebook/pdf_bw/

[ebo]

From time to time I start getting weird behavior that makes me think that my keyboard shortcuts are being remapped -- maybe I hit caps-lock or something. When that happens I completely restart the notebook, and undo's work again. Today it started doing this again and messed my notebook up so bad I lost a full days work and was unable to recover.

Suggestion/feature-request: add undo/redo to the edit pull down menu so I can force the behavior.