[WIP] Adding classic shortcuts extension

[RRosio]

• Enable/Disable mechanism
• Delete line shortcut

[github-actions]

👈 Launch a Binder on branch RRosio/notebook/classic-shortcuts

[jtpio]

Thanks @RRosio for looking into this!

This would help some folks migrate from the classic notebook to Notebook 7.

Wondering if this new extension should only be available in Notebook 7 though? Or could it be that some JupyterLab users would also like to have this set of keyboard shortcuts available? If so, maybe it should be its own extension? (for example in https://github.com/jupyterlab-contrib)

[jtpio]

Relevant issues:

• Support keyboard shortcuts available in Jupyter Notebook jupyterlab/jupyterlab#14738
• [Request] Keyboard shortcut parity with notebook classic #6596
• Fix keyboard shortcut regressions in new Notebook interface #7041

[RRosio]

Thank you for taking a look at this @jtpio!
Initially I was thinking that maybe it would not be an extension that we would necessarily expect to see in JupyterLab because there was no previous indication (to my knowledge) that JupyterLab would provide parity with the Notebook v6 user experience. I appreciated with this extension in the Notebook 7 codebase that there would be easy access to enable with a few minimal clicks. I guess my biggest motivation to develop the extension outside Notebook 7 codebase would be whether it should be used with JupyterLab, but I am not sure that there is a precedent for that? Would you have a bias toward one option or the other?

[jtpio]

Initially I was thinking that maybe it would not be an extension that we would necessarily expect to see in JupyterLab because there was no previous indication (to my knowledge) that JupyterLab would provide parity with the Notebook v6 user experience

True. Maybe the main advantage would be to have a coherent set of shortcuts between JupyterLab 4 and Notebook 7.

I appreciated with this extension in the Notebook 7 codebase that there would be easy access to enable with a few minimal clicks.

Normally the number of clicks or other UX considerations should not depend on whether an extension lives in a different repo? Unless it requires an extra pip install to install it.

I guess my biggest motivation to develop the extension outside Notebook 7 codebase would be whether it should be used with JupyterLab, but I am not sure that there is a precedent for that? Would you have a bias toward one option or the other?

So similar to the custom CSS feature, maybe the best would indeed be to develop the extension in the notebook repo like in this PR, and include it as part of the Notebook application but not the JupyterLab application.

If some users show interest to have the extension enabled in JupyterLab as well, we could convert the extension to a regular JupyterLab extension but still develop it in the notebook repo. Like the lab-extension package in this repo: https://github.com/jupyter/notebook/tree/main/packages/lab-extension

[jtpio]

Adding to the 7.1 milestone as a nice-to-have feature: #7087

[jtpio]

@RRosio just checking in to see if you would like to have this for the 7.1 release?

I would like to publish a first 7.1 beta release soon, to try to stay in sync with the JupyterLab release cycle.

Otherwise no problem to postpone it for later and consider that for 7.2 (or a separate extension to start with).

[RRosio]

Hi @jtpio sorry I didn't see this message earlier! I think I would like to say this could be ready for a 7.2 release rather than 7.1, it is still not working quite like I intended and it is a bit flaky at times. I am working on it but if I fix it quickly and a 7.1 release is happening soon I don't want to hold it back.

[evdcush]

Hi @jtpio @RRosio,

Thanks so much for working on this! 🙏🏻

This is an important/required feature for notebook power users (speaking for myself and several teammates of mine), so I'm glad to see a little bit of activity here.

It's maybe worth mentioning that folks who have worked for years in nb "classic" don't give notebook 7 or jupyterlab more than a few seconds chance, if that, because the ui elements or what it is that nb 7 features/targets, are not worth the hit to velocity or loss of utility one has in classic.

Feature parity with classic should be the acceptance criteria for updating notebook.

So I appreciate your support here! I hope this gets higher priority!

(Context for this comment being my team's env got bumped onto 7 by accident and we had to revert)