On Tuesday, 22 August 2017 20:48:56 UTC+2, Edward K. Ream wrote: > > On Tue, Aug 22, 2017 at 7:32 AM, Josef <joe...@gmx.net <javascript:>> > wrote: > >> For me it is all about usability. >> > > Yes. People like you who actually use Jupyter have insights that I don't > have. I welcome all your suggestions. > > > > I want to be able to write code, clone bits and pieces here and there, > disable some code. > > This I do either by moving it out of the script tree or by commenting it > out. > > @ and @c work, but I am missing @ignore in @other trees, as it would make > visually clear, which nodes are disabled. > > @ignore can never happen in @file and @auto trees because all information > resides in the external file, so if gets ignored it is gone for good. > > @ignore could be valid in @nosent trees, because all data remains in the > outline. However, at present Leo rejects @ignore everywhere. This seems > like a mistake, but I don't think it will help you to fix it because you > must use @auto. >
I was hoping to be able to read into an @clean node instead of using @auto or @nosent, as I need to cooperate with others, not using Leo. > > > Compatibility with .ipynb files would be nice, particularly in order to > exchange files, and putting them on the web, > but also to switch back and forth between Jupyter and Leo. > I don't think Leo needs to implement all the nice pretty-printing stuff > (@pyplot), plotting into a qt window is fine, > although with longer scripts it may be good to be able to select which > plots to execute, and which not (again @ignore?). > > What do you mean by compatibility? Are you suggesting that Leo could > write some parts of outlines as .ipynb files? > yes. But note, I am only an occasional Jupyter user. Still some people I work with might be inclined to cooperate via a Jupyter file, while I am sceptical about them using Leo - sadly. Jupyter is not a high priority for me. Cooperation on latex files is. JupyterLab (the new and still unfinished version of Jupiter) seems to have some nice features, but I guess, I will still continue to work with Leo instead, because I need more control over the Latex output than Jupyter provides. > > > > It would be good if the read .ipynb files can be run as a script within > leo if they only contain python code, > or using the ipython bridge when there is ipython code (a bit clumsy to > have to start leo from the command > > line in this case). > Of course, the written back .ipynb files need to remain compatible with > jupyter. > > Interesting idea. The present .ipynb importer is just that: only an > importer. Perhaps a post-pass could massage the imported nodes into a more > useful form, squirreling away less useful data somewhere for eventual use > by the exporter. > That's what I had in mind too. > > > > > I also would like to see features, to export selectively certain sections > to Latex: > Jupyter can export to Latex too, but I found a 1:1 copy not useful for > inclusion into a paper. > I need more control over the latex output, and by latex I mean not only > formulas. > I would like to export some text and output of calculations (tables, > graphics) to latex snippets, > which would then be \input to a latex document. > > As always, > the most general and flexible solution to such problems is a custom > script, which by definition can do anything. > > > Having said that, it is simpler to define some kind of framework for > specifying desired parts of text. This could be done using additional > markup. Would this be useful? If so, I would glad to help you with such a > project. > In principle I like the idea of such a framework (may be more general than just for work with latex documents). Thinking more about it, I don't think I want to just export, but whatever ends up in latex must be in @clean trees, because my co-workers may end up editing these files too, so I need round-tripping. For that, @clean seems to suit best, but I have difficulties to organize the @clean nodes in a fashion that reflects the document tree semantically. Latex files can be split by \input statements, but these may not be all on the same hierarchical level, but could even be nested, while @clean nodes cannot be nested as far as I know. If nested @clean nodes ever become viable, great. In the meantime I stick to having the @clean nodes all on the same level and linking them to the nodes in the document tree, where they are \input. - Josef > > -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
