It sounds sort of like the LightTable editor, and others which offer 'live' feedback
ipython is one-dimensional, rendering is simply 'next' or 'below' Leo's richer interface makes it less obvious what it would look like. Where would you expect Leo to put the rendering? - split the edit pane (shrinking the active one) - create a child - create a sibling - use a new log pane - pop up like stickynotes - ... On Fri, Jan 30, 2015 at 4:11 PM, Edward K. Ream <edream...@gmail.com> wrote: > This is definitely something I would like to do. It's inspired both by > IPython's output cells, and by our recent discussion of "magic" cut/paste. > > As you know, IPython will print the results of evaluating an input cell in > the corresponding output cell. This is a an extremely useful (and cool) > feature. > > Iirc, if an object has a "display" method, IPython will use that method to > display the object. Details fuzzy, and perhaps not all that important for > this discussion. > > Leo could do something similar. Suppose we can define the results of > executing a script, as IPython does, perhaps exactly like IPython does. If > the results are not None, and can be rendered (displayed), Leo would > automatically open the viewrendered pane and show the results there. > > Voilá, Leo would gain most of the capabilities of the IPython notebook, > while retaining all of Leo's superior features. Happily, it should be > possible to prototype this scheme with relatively little work. Maybe we can > even cut/paste a relatively small amount of IPython code. > > All this can be done by extending Leo's execute-script command. Kinda like > a read-eval-print loop, without all the read complications :-) > > I've been thinking of this for a week or more, but the discussion of "rich" > cut/paste crystallized my thoughts. In essence, Leo would be "pasting" the > results into the vr pane and displaying the results in the most interesting > way available. The vr pane should at least the same display capabilities as > IPython output cells. > > It's really that simple. > > Imo, this would be a huge step forward for Leo. For the first time we would > have a general, extensible framework for rendering. Furthermore, we can > re-imagine the vr pane as an output cell. It might even be possible to > eliminate explicit @html and @image and @svg nodes: the body pane could > *always* be for "sources"; the vr pane would *always* be for rendering. > > As discussed before, we could cache renderings (or the objects to be > rendered) in p.u, and re-display p.u when revisiting p. This would make Leo > very similar in concept to IPython, without having to slavishly recreate > IPython eccentricities such as permanent namespaces. > > These last couple of weeks have been slogs through documentation and code. > But this one idea, all by itself, seems worth the effort. What do you > think? > > 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 leo-editor+unsubscr...@googlegroups.com. > To post to this group, send email to leo-editor@googlegroups.com. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
