The aforementioned extension is an nbextension only; it doesn't need an extension on the server or a change of the notebook format. It works by creating a CKEditor instance in front of a markdown cell and then embedding the HTML/markdown produced by the editor in the document once the user is done editing.
A CKEditor 5 version is in development but hasn't been merged into master yet: https://github.com/genepattern/jupyter-wysiwyg/tree/ckeditor5 Thorin Tabor On Tuesday, August 6, 2019 at 1:00:28 PM UTC-4, Tony Hirst wrote: > > Just for completeness (?) on this thread in sense of cross-referring to > other attempts at notebook wywiswg tools, I'm not sure how the > https://github.com/genepattern/jupyter-wysiwyg extension handles things > (it seems to drop HTML into an enabled markdown cell, which can get really > messy after a bit...) > > --tony > > On Friday, 2 August 2019 08:17:04 UTC+1, Tim Head wrote: >> >> This looks great! >> >> A while ago I experimented with adding WYSIWYG (to nteract). One of the >> problems to solve was exactly the question of "how do we do this without >> extending the notebook format". The answer I found is that some of the >> editors (like draft.js) are able to round trip markdown to their internal >> format. If you want to take a look at what I did back then >> https://github.com/nteract/nteract/pull/3699. >> >> T >> >> On Fri, Aug 2, 2019 at 3:16 AM Jonathan Gutow <[email protected]> wrote: >> >>> >>> >>> On Thursday, August 1, 2019 at 7:15:27 PM UTC-5, Jason Grout wrote: >>>> >>>> This looks really cool! >>>> >>> Thanks. Glad you think it has potential. For me it solves a serious >>> problem with convincing non-programmers to try Jupyter for simple things, >>> because it flattens the learning curve for producing notebooks containing >>> instructions for our students. >>> >>>> >>>> I would suggest that if at all possible, you work within the existing >>>> notebook format and not introduce a new cell type. There is a massive >>>> amount of momentum behind the notebook format as it stands. >>>> >>>>> >>>>> I am not sure it is possible. The WYSIWYG cell is an extension of the >>> basic cell type not the textcell (e.g. markdown). This means a new cell >>> type had to be defined, so that it would be interpreted properly. >>> Presently, the cell data is stored as a wordprocessor-like 'delta' json >>> object. At best, I can imagine a way to store the data as raw html to >>> maintain the formatting, but that would generate more overhead when loading >>> a notebook (still, this might make issues with nbconvert simpler to >>> address). All that said, the extended notebook format is the addition of a >>> new cell type to the present format, so can read the present format, with >>> zero issues. Going back the other way is more of an issue. It is probably >>> best to convert the new cell type to html code cells or raw nbconvert cells >>> with html content when going backwards. We are definitely struggling with >>> the back conversion issue. >>> >>> Jonathan >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Project Jupyter" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jupyter/d0340d82-2f3a-48e7-ad1d-ee2c54cd0104%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jupyter/d0340d82-2f3a-48e7-ad1d-ee2c54cd0104%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/d333588a-07ba-453c-b027-a33dc35a9a36%40googlegroups.com.
