On Saturday, October 26, 2024 at 8:03:34 AM UTC-5 [email protected] wrote:
There has been a flurry of activity in the last few weeks to add an ability for working with Jupyter notebooks by means of an intermediate file format. That format is provided by the jupytext program. However, in the rush no one seems to have thought much about what Leo can bring to the table, or why anyone would want to use Leo for this purpose, compared let's say with the Jupyter plugin for Visual Studio Code, which seems very good and very readable to me. Huh? @jupytext makes it possible to organize Jupyter Notebooks with Leo outlines. What more do you want? For those who don't know yet, a Jupyter notebook's file format is JSON. JSON was designed to interchange data, including program structures. It was not designed for documentation or readability. Yes, and @jupyter mostly hides the details. Any markup such as Leo's sentinels that are needed to support structure or other Leo features are hidden from the user. There's hardly any visual clutter. IMO this is a crucial feature that Leo offers. It makes writing code to save and restore outlines and external files very complicated, but the user doesn't need to know about that. I agree. Leo is not nearly as capable in supporting writing and documentation. Huh? What about LeoDocs.leo?? The Leonine Way ------------------ 1. Leo should present a view of a Jupyter notebook file to the user without sentinels or visual clutter, just like it does with other external file types. @jupytext does this. 2. Leo should be able to recreate the file's structure on reloading, or at least a close approximation to it. @jupytext does this. @jupytext uses the @clean update algorithm. 3. Code cells should be syntax-highlighted and preferably able to be at least syntax-checkable. That could be done, but it wouldn't be easy. I'm not interested. 4. Code execution would be a bonus but not required. This is a misguided goal. Leo *cannot* even closely approximate the environment provided by Jupyter Notebook. Attempting to do so would be a waste of time. 5. The user should need to know a minimum of special forms such as directives or other special markup features, and if there are any they should have a form similar to other Leo forms. The user needs to know about Jupyter notebooks. 6. There should be a way to show a view of adjacent or nearby nodes so that the user can make sure they work together as intended. Showing a fully rendered view of nodes' Markdown is a desirable bonus to avoid round-tripping to Jupyter. VR3 is free to do anything it likes. 7. There should be an easy way to extend the file handling and rendering capabilities to use other programming languages besides Python. The only available Leo setting is @string jupytext-fmt = py:percent. The jupytext documentation is far from clear on the meaning of this option. 6. The process of converting, importing, and exporting the files should be invisible to the user, just as for any other external file that Leo currently supports. It already is. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/leo-editor/71208222-2510-43bb-9f61-67dff6113ffan%40googlegroups.com.
