On Wed, Mar 22, 2017 at 10:05 AM, 'Terry Brown' via leo-editor < [email protected]> wrote:
> > > 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 ;-) > Yes. That would be best. > > 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. > Yes. I was just thinking that a Publish/Subscribe pattern for notifications might be good. > > 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. > I don't remember that in detail. I think we are both agree that we should approach such "grand" ideas with suitably "humble" changes. 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. > Imo, the way forward is to go after low-hanging fruit. A pub/sub architecture may yield large benefits with few changes to the code. Or not. > > 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. > Yes. We want to make minimal changes to the code. > > 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. > I agree. 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. > Exactly. c.p permeates every aspect of Leo's code. Switching c.p is what makes the present multiple-body-editor code so damnably complex. 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
