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.
