Feature parity with current notebook

[jasongrout]

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.

• Widgets (Widgets #34) (changes how widgets are displayed)
• Multiple-cell selection
• keyboard navigation / shortcuts
  • 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.) Trigger tooltips on shift-tab jupyterlab/jupyterlab#714
• edit notebook and cell metadata
• Changing kernels
• Dealing with large output (in classic notebook, clicking on output prompt switches output between hidden, constrained-height, and full-height)
• Notebook trust features
• tab completion in editor
• Cell toolbars Implement "cell toolbar" for notebooks jupyterlab/jupyterlab#902
• undeletable cells
• 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.

[jasongrout]

CC @ellisonbg, @blink1073, @rgbkrk ... wow, this will be a long list. I'm just going to send an email to everyone.

[blink1073]

I would add the output area prompt overlay (which I didn't even know existed until I was trying to clone the notebook).

[blink1073]

Plus the ability to edit cell metadata.

[blink1073]

And changing kernels (which I'm working on now).

[jasongrout]

what is the output area prompt overlay?

[blink1073]

I'll make a screencast.

[jasongrout]

Is it the clicking on the output area to change the max-height of the output?

[blink1073]

[jasongrout]

yep, that's really useful. In Sage, we also had a mode that would wrap text.

[jdfreder]

Tab completion?

[jasongrout]

Thanks

[jhamrick]

• Ability to edit notebook metadata
• Cell toolbars
• Undeletable cells

[jasongrout]

undeletable cells? We have that? How do you do that?

[Carreau]

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.

[Carreau]

• Tooltips (shift tab)

[jhamrick]

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.

[jhamrick]

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).

[jasongrout]

oh yeah, right!

[sccolbert]

Do debuggers work currently?

[jdfreder]

ipdb works

[blink1073]

Can we agree on a subset of these for an alpha release, to get earlier feedback?

[rgbkrk]

[minrk]

@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.

[blink1073]

@minrk, I've got a bit more that I'd like to do before making a PR against master, hopefully early next week.

[jasongrout]

@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.

[blink1073]

Round 1: jupyter/notebook#1201

[ellisonbg]

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.

[Carreau]

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.

[fperez]

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...

[fperez]

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.

[jasongrout]

@fperez - would it be enough to have a button to maximize the current notebook, which maximizes the current tab so that it fills the dock panel or the browser window? What are the use cases for having the URL reflect a single document?

Edit: We could provide a right-click -> Open in new tab (or maybe middle click on the filename would open a new tab, to keep the browser paradigm?). However, we need to think through how this works with the plugin and extension system. The extensions right now are hooked together in the Lab application, but we'd want the same plugins registered and working in your single-page view too. Perhaps a right-click -> open in new tab could open a new JupyterLab with the single notebook maximized by default...

[ellisonbg]

The point @fperez brings up is super important and worth of its own issue:

#158

A short summary is that this feature is absolutely critical.

[ellisonbg]

And another issue about keyboard navigation in the dock panel: #159

[blink1073]

@jasongrout, do you mind taking a pass through the list above and checking off the things we have hit, and then I'll create separate issues on jupyterlab with Notebook and Feature Parity labels for the ones we have not already tagged there?

[jasongrout]

@blink1073 - I checked off a few and added a few references to existing issues.

[blink1073]

• What is the printed stylesheet?

• Convert to a variety of formats: Add "Export to ..." into the menu jupyterlab/jupyterlab#964

• Find and replace: Create document wide search and replace feature for file editor/notebooks jupyterlab/jupyterlab#1074

• Commands: Ensure notebook command parity jupyterlab/jupyterlab#1306

• Help links: Handle help links from kernels jupyterlab/jupyterlab#1307

• ? and ?? are handled by redirecting pager output

• Metadata are handled by Add UI for editing notebook metadata jupyterlab/jupyterlab#1308 and Implement "cell toolbar" for notebooks jupyterlab/jupyterlab#902

• Large outputs: Better UI/UX for handling of large outputs jupyterlab/jupyterlab#1309

• Undeletable cells: Handle undeletable cells jupyterlab/jupyterlab#1310

[jhamrick]

Related to undeleteable cells is now also the read-only cell metadata; I'm not sure if that was handled here or not yet: jupyter/notebook#1482

[blink1073]

Thanks @jhamrick, I opened jupyterlab/jupyterlab#1312 to track that one.

[jasongrout]

What is the printed stylesheet?

I think it's CSS for the print media type - so you can hit the browser's print button and get a nice looking printout. I'm not sure what that would look like for lab, though, given multiple notebooks on a page. Perhaps that can be shelved in the backlog until we have a good way to view a notebook on a single page, or at least until we can tear notebooks out to child windows (and then hit print..)

[blink1073]

We could offer up the most recently focused document for printing.

[blink1073]

(In theory, I'm not familiar with using the print media type).

[blink1073]

Tracked in jupyterlab/jupyterlab#1314, marked as 1.0 so we at least look at it.

[jasongrout]

It's just another selector in css - https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Getting_started/Media.

Perhaps we could do something like that. If there is a CSS class applied to the currently active document, we could do something like @media print .document:not(.active-document) {display: none} or something to hide everything except the current document. Interesting...