On Wed, 22 Mar 2017 06:35:12 -0700 (PDT) "Edward K. Ream" <edream...@gmail.com> wrote:
> Up until now, I have never regretted using separate outline and body > panes. For coding especially, there are advantages: all body text is > unindented, regardless of its position in the outline. > > However, "embedding" outline text does have advantages, as both the > Quiver overview > <https://github.com/HappenApps/Quiver/wiki/Getting-Started#5---preview-and-presentation> > > and the Englebart video <https://vimeo.com/81238285> show. In > particular, outline heads can be "rendered" in place, according to > outline level, context and user preferences. > > Unifying the outline and body panes would require changes throughout > Leo. It seems too big a project, but I am playing with the idea. The > Englebart video is tantalizing. If such a thing were to be done, I think it should be done without making any changes to Leo ;-) I think Leo will become much more powerful / flexible when it has multiple node editor components that are free to act on different parts of the tree. In fact I posted a screenshot of a column of Leo Edit Pane (LEP) widgets which effectively interleave headings and bodies just a couple of weeks ago. Of course "no changes to Leo" is disingenuous, Leo will probably require changes to most efficiently support such components, although LEP hasn't required any yet. But if a unified outline editor should arise, I think it should not replace the exiting tree and body editor, but be an example of one of these new node editor components that are free to act on different parts of the tree. The current tree and body panes need not be visible, but they shouldn't be replaced. It should be possible to have the current tree and body panes and the new unified editor visible at the same time. I'm repeating myself but I think it's key that there not be one component (currently the combination of the tree and body panes) that can edit a Leo outline, we need more decoupling of editing from the core Leo outline / data structure. LEP is an example. I've found it relatively easy to have a QTextEditor widget editing this node, and a QScintilla widget editing that node, with the LEP layer handling node selection. Where I've stalled is getting a LeoQTextEditor widget into the mix. Perhaps the big shift in thinking is c.p. That would become "the node selected in the tree". Which it is currently, the difference being for a given node editor component, that component might not be editing c.p. So there will be issues to resolve for executing scripts, etc. etc. Cheers -Terry > Kent has long requested unified *file *views. The VR2 plugin > provides one way to get that for a given tree, but it could be > improved. > > Jupyter provides such integrated views without outlines. Links and > TOCs must be entered by hand, but the visual effect is good. > > All such options could be called preferences, so it's no good arguing > about them. Leo needs to do better in this regard. #443: Adopt > Quiver Look and Feel > <https://github.com/leo-editor/leo-editor/issues/443> contains links > to many other related issues, so #443 is probably a good enough > placeholder. > > Your comments, please. > > 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
