Add button to toggle Markdown/Prosemirror

[Zsailer]

I think it would make sense to add a toggle switch to turn Prosemirror mode on/off without having to disable the extension.

This is especially useful when we add a Prosemirror editor outside notebook. The full Prosemirror editor should always be available, but the notebook Prosemirror mode is toggleable.

[bollwyvl]

What this also potentially hints at is a MultiEditor in the factory, which can draw either of these editors, or an unknown, future editor you install as another plugin. It would likely be appropriate to develop it here (since you have two editors of interest) but figure out how to make it extensible and get it back into Lab core.

Otherwise: sometimes when you're writing, you want to Writing. I'd like to see come over from jupyterlab-outsource: a New view for editor command and context menu entry. Would need to figure out how to get the editor to draw its own toolbar.

[Zsailer]

Hey @bollwyvl! Great to see you here! @dLamSlo8 and @isabela-pf drew inspiration from your project deathbeds/jupyterlab-outsource.

a MultiEditor in the factory

This is a great idea (and something @dLamSlo8 and I talked about before). Derek will explore further.

[Zsailer]

@bollwyvl — separate question?

Do you think this project should eventually merge with jupyterlab-outsource? We can work towards a PR in your direction.

[bollwyvl]

merge with jupyterlab-outsource

While it is released on npm, i would see jupyterlab-outsource as continuing to be more of a playground. It's basically just me hacking on it there :P

For this repo, I would see a PR to jupyterlab/jupyterlab as the best possible exit. If the multi-editor thing figures itself out, and users doesn't have to download the prosemirror (or whatever stack eventually gets chosen) stack until they ask for it, whatever state it gets to, this feature is far too useful to be hidden behind an npm install and webpack build.

An ambitious gate for being a default (or at least recommended) lab ui would probably be to have a compelling story for most of the advanced features of jupyter markdown:

• tables
  • https://github.com/ProseMirror/prosemirror-tables
• equations
  • http://mathquill.com/
• simple drawings
  • https://github.com/SVG-Edit/svgedit
• attachments

Beyond that, one could imagine something akin to what @gnestor had demonstrated at JupyterCon (sadly, i don't have a link!). Basically, replace the UX of "infinite streams of discrete cells" with something like "a continuous prose document with embedded artifacts of compute". Still stored in an .ipynb, also editable in the cell-based interface, but much more approachable.

To enable this, and assuming Prosemirror, a schema could be created that instead of just capturing commonmark, instead captured the whole nbformat.

But again, I'd say what you've scoped out appears to be something that should try for lab core, even it it isn't going to disrupt word/lyx.

[Zsailer]

i would see jupyterlab-outsource as continuing to be more of a playground.

:+1: 😃

An ambitious gate for being a default ...

All these things are on @dLamSlo8's roadmap. This is fantastic!

Basically, replace the UX of "infinite streams of discrete cells" with something like "a continuous prose document

Funny enough, @markellekelly and @javag97 also been exploring a "continuous prose document" experience while building jupytercalpoly/jupyterlab-clarity-mode (though it's not up an running just yet). There is a lot of experimentation happening there, but they've ripped out the notebook extension from lab (or its components rather) and puts those components back together in new ways. The new document that is emerging looks something like continuous prose with notebook cells for compute. It's not quite as far as @gnestor's proof-of-concept, but definitely in that direction!

[gnestor]

Funny enough, @markellekelly and @javag97 also been exploring a "continuous prose document" experience while building jupytercalpoly/jupyterlab-clarity-mode (though it's not up an running just yet).

This is exciting!! I'd love to collaborate on this. Is the plan to use ProseMirror? I've used Draft.js and Slate.js in the past, both have their pitfalls, I've found that Slate.js has a much nicer API and is more actively maintained, but neither support realtime collaboration, so I've been looking at ProseMirror lately...

My Dynamic Docs POC uses the nteract binder React components to connect to a MyBinder instance and get a kernel and the nteract output-related React components to render outputs using a set of mimerender components. It doesn't use any JupyterLab components but it would be cool to see an implementation that does. It also doesn't store docs in the notebook format, it exports docs to Slate.js's JSON format and saves them to Google Drive, but exporting to notebook JSON would make these docs interoperable with any other Jupyter clients 👍

[javag97]

We are welcome to your help and feedback @gnestor!

[Zsailer]

exporting to notebook JSON would make these docs interoperable with any other Jupyter clients

@dLamSlo8 is discovering that adding rich text editing to notebooks disrupts the "stream of discrete cells" model in current notebook clients. UX like command+edit mode in lab doesn't make sense anymore, because you don't need to "run" text/markdown cells.

One way to get a "continuous prose" experience is to make prosemirror editor "cells" sandwich code cells and vice versa. That's how the nbformat would see it, at least. In the UI/UX, the prose portions of the document wouldn't feel like "cells" per se. Every space between code cells becomes a rich-text editing experience. When this document is saved, however, the notebook JSON looks like code cell, markdown cell, code cell, markdown cell, etc. This can be opened in other jupyter clients.

[bollwyvl]

edit mode in lab doesn't make sense anymore

Considering the formatting already implemented, and those imagined above, full WYSIWYG has the potential to consume a lot of additional screen real estate that just wouldn't be relevant if you switch to code editing. Indeed, the default rich text editing state, Write, could be more distraction-free, relying on keyboard shortcuts and input rules (e.g. starting a line with - makes a list).

Edit could in turn be more like what an Editor, (as in the job in a newsroom), would see, and so would include all of the formatting buttons, maybe change tracking.

Another direction to consider would be more like the WYSIWYM, e.g. Lyx:

• imagine the minipage and outline only showing in edit mode
  • 
  • ...where the embedded pieces are clickable configurations for each of the items.
  • ...but you wouldn't want to see them if just reading a document