jupyter-js-notebook
jupyter-js-notebook copied to clipboard
jupyter
Feature parity with current notebook
This is a meta issue listing high-level features of the current notebook we need to address in a new implementation. We may decide that a feature is not worth implementing, or that we want to implement it differently.
- [x] Widgets (#34) (changes how widgets are displayed)
- [x] Multiple-cell selection
- [x] keyboard navigation / shortcuts
- [x] continuous keyboard traversal of cells with up/down in edit mode, rather than stopping hard at cell boundaries, forcing the user to 'pop out' to command mode to move between cells. Basically, when you press the down arrow at the bottom of a cell, it moves to the next cell in edit mode if it is a code cell. I think the current notebook also will change a markdown cell to edit mode, which to me is confusing. Similarly for the up arrow when at the top of a cell.
- [ ] printing stylesheet
- [ ] convert to variety of formats (current notebook "File > Download as" menu)
- [ ] Find and replace
- [ ] a variety of commands (compare with command list in current notebook)
- [ ] help links
- [ ]
?and??introspection (we have?, but seeing??requires opening the inspector manually - perhaps??should expose a link to open the inspector to guide the user?) - [ ] tooltip help (function signatures, help, etc.) https://github.com/jupyterlab/jupyterlab/issues/714
- [ ] edit notebook and cell metadata
- [x] Changing kernels
- [ ] Dealing with large output (in classic notebook, clicking on output prompt switches output between hidden, constrained-height, and full-height)
- [x] Notebook trust features
- [x] tab completion in editor
- [ ] Cell toolbars https://github.com/jupyterlab/jupyterlab/issues/902
- [ ] undeletable cells
- [x] input/raw_input working (for things like pdb)
From @ellisonbg below:
- Pager (this should be a separate area on the page rather than in the notebook widget itself)
- Output scrolling and collapsing need to be reworked, keeping in mind that we also want to allow input to be collapsed. We should have a nice unified UI for doing both of these things.
- Cell tooltips (shift-tab) should be unified with regular tab completion (tab) into a single nice UI/UX.
CC @ellisonbg, @blink1073, @rgbkrk ... wow, this will be a long list. I'm just going to send an email to everyone.
I would add the output area prompt overlay (which I didn't even know existed until I was trying to clone the notebook).
Is it the clicking on the output area to change the max-height of the output?
yep, that's really useful. In Sage, we also had a mode that would wrap text.
undeletable cells? We have that? How do you do that?
Not in UI. If you tag a cell with the right metadata it cannot be deleted.
Not in UI. If you tag a cell with the right metadata it cannot be deleted.
Yep, exactly. This is a really important feature for nbgrader to prevent the cell metadata that nbgrader relies upon from being lost.
Ooh, here's another one -- not sure if this falls under widgets but making sure input and raw_input work (and relatedly, debuggers like ipdb).
Can we agree on a subset of these for an alpha release, to get earlier feedback?
@blink1073 for getting it turned on in master, it might be ready now. We don't need anything close to all this for people to start playing with it, if you want to make a PR re-enabling notebooks in Lab.
@jasongrout We should be careful a bit with parity, because we don't necessarily want to copy everything over. Some things like the output-collapsing UI do not need to be inherited as-is, or even mimicked. We can start from more basic requirements like "Dealing with large output" and work from there.
@minrk, I've got a bit more that I'd like to do before making a PR against master, hopefully early next week.
@minrk - definitely. My idea in making the list isn't that we necessarily have to implement exactly what the current notebook has, but that these are the things that people are expecting and we should address. However, we definitely can rethink them. For example, we are changing how widgets are displayed. I can see that wasn't clear from the title, so I'll modify the wording there.
I agree with @minrk that there are some things that we should not implement with the same UI/UX as the existing notebook:
- Pager (this should be a separate area on the page rather than in the notebook widget itself)
- Output scrolling and collapsing need to be reworked, keeping in mind that we also want to allow input to be collapsed. We should have a nice unified UI for doing both of these things.
- Cell tooltips (shift-tab) should be unified with regular tab completion (tab) into a single nice UI/UX.
Cell tooltips (shift-tab) should be unified with regular tab completion (tab) into a single nice UI/UX.
We should be able to do that in terminal console as well with prompt-toolkit.
I think many folks are going to really be thrown in for a loop in their workflows if we don't offer a way to open a notebook by itself in a single tab with a stable URL. It's extremely useful and it lets people continue using their muscle memory (tab shifting in the browser via keyboard) and tab management tools.
I'm finding it very hard to adapt to not having that (even though I like the combined lab layout also for other things, I'm only suggesting we need the option of a single-notebook-at-url). I suspect others may encounter the same in everyday work...
Another one: continuous keyboard traversal of cells with up/down in edit mode, rather than stopping hard at cell boundaries, forcing the user to 'pop out' to command mode to move between cells. This makes the editing workflow as it currently works ('hard stops') very painful.