What I'm getting here is that a split is a way to reference another node by creating a type of "copy" of *just that node with no children*. I think this is the most important characteristic.
If there is a command "split-node" it should be atomic, creating a type of "copy" of *just that node with no children.* It should not a combination of commands (split node then clone children of original node as children of split node). If you see the need for additional functionality that should be a new command, "split-node-clone-children". Otherwise you're going to get confusion by people seeing behavior identical to clones but with a different icon box marking for the parent and children? I can see where they would be confused! I think the word split is a misnomer with an unfortunate similarity to the word clone, it's more of a "referenced node" than anything else. Which by your example use case of documentation sounds like a better name for them. That is double the amount of letters, referenced vs split, but conceptually as much distinction as possible needs to be made compared to clones. Split and clone are just too similar. On Wednesday, March 23, 2016 at 9:01:26 PM UTC-4, Edward K. Ream wrote: > > Awhile back I got excited about multi-threaded trees. You can think of > them as allowing nodes to have different-colored links. > > But it seems that this scheme would be hard to understand and use. It > implies a whole series of commands that copy/paste from one set of threads > to another. Too much complication; too little benefit. > > The primary use case guiding my thinking is documentation. We often want > to discuss a node *without* necessarily discussing all its descendants. > Split nodes might allow us to handle this while still having all nodes be > part of a single, always accessible, tree. > > Spitting a node creates two *separate* vnodes that share only their > headline and body text.The split *copies *their children and parents > arrays, thereby creating *clones *of all their children. After the split, > split nodes can be moved independently of each other. Children of split > nodes can be changed independently. That's pretty much the whole idea. > > Very little changes behind the scenes: > > - The v.b and v.h properties will do one extra level of indirection, to a > shared data structure. > - Leo's read and write code will change (slightly?). > - The number of Leo's icons for the icon box doubles, so that a node can > be cloned, split, marked simultaneously. > > I think that's about it. > > Let's return to the motivating use case. To document a node, we would > split it and move one of the "splits" to the documentation area of the same > outline. The writer could delete (or move!) any child without affecting the > other "split". This would fulfill a long lasting dream, and do it with a > minimum of fuss. > > 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.
