jupyter / notebook

Jupyter Interactive Notebook
https://jupyter-notebook.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
11.74k stars 4.98k forks source link

Add option to remove trailing cell on save using the content manager #1928

Open mpacer opened 7 years ago

mpacer commented 7 years ago

In discussions with @ian-r-rose we realised that many notebooks have an extra cell at the end of the notebook due to execution with the ↲ command, which automatically creates a new cell.

These cells (being empty) have no effect on the output other than to make it look somewhat sloppy when sharing notebooks.

This seems like a common enough use case that it'd be worthwhile having a configurable option that could just create a presave hook that will remove this cell.

Some complications:

If there were more than one cell my assumption would be that it was intentional and so this removal would not be applied.

One UI concern that we might have with this is the possibility that this cell is actively selected/being edited at the time that save is invoked, in which case this shouldn't be executed. Other than that though it doesn't seem like this would create many issues and would make for nicer default output for many people. Because it would be an opt-in solution and always keeps a valid notebook file; there would be no compatibility worries.

NB: I'll work on this later, this was a sidetrack from something else I was doing and it led me down another rabbit hole related to the documentation I link above. I'm just posting this for my further reference.

rgbkrk commented 7 years ago

Heh, I notice this as well and it manifests mostly when I'm demoing a notebook or recording a screen capture. I'll delete the last cell for the sake of cleanup then.

However, when I'm exploring the notebook I'll keep lots of empty cells around. Plenty of freedom to be messy -- I would be bothered by auto-cleanup.

mpacer commented 7 years ago

tldr; sounds like you should be fine if you have lots of empty cells around, since this wouldn't affect most of those cells (none of them if multiple cells are at the end).

I understand keeping empty cells around; but this actually wouldn't affect that in most cases. Any cells in the middle would be untouched. The solution I proposed was not removing anything if there were at least 2 cells at the end.

I had originally proposed it be off by default, but now that I'm thinking about it, there's a good case for making it default. It actually wouldn't affect anyone who likes keeping lots of cells around at the end, and if it were default it would make more people's demo'd/example/screencast/expository/documentation notebooks nicer to look at.

And, if the feature were on by default, the thought was it'd always be possible to just turn this off using a configuration option.

Bonus: it sounds like you could achieve both the upside at the same time as preserving your workflow. I.e., my guess is you wouldn't be bothered in practice because the auto-cleanup wouldn't affect any of your "middle" cells (preserving exploration) and it would only remove at most one at the end (and only if there was exactly one, that you hadn't been interacting with). That one cell being deleted would be as easy to recreate as it is to navigate to the cell; just one keystroke (assuming you're either using the keyboard shortcuts or autocreating cells by executing code with ↲).

ellisonbg commented 7 years ago

Yeah I deal with those empty cells as well. Note sure how to handle this in a reasonable way though - much of the time there are there because I am still working and use them shortly.