On Thu, Feb 11, 2016 at 7:03 PM, Kent Tenney <[email protected]> wrote:
> I'm trying to see the use case. > So am I ;-) > I know you use clones to gather scattered bits which are relevant > to an issue. I'm seeing this 'colored threads' concept applying like this: > > The 'black' thread has nodes arranged in code-correct order, as they > would need to be presented to the interpreter. > Exactly. I should have said that. > > The 'red' thread is the arrangement which I currently see in the body > pane, with the currently interesting nodes isolated for convenience. > > The structure of the .leo file is more arbitrary than before, since node > attributes define multiple arrangements, though I suppose there would > be a default, 'black' in this case. > Yes. The structure of the outline has always been somewhat decoupled from the "black" thread. Now, however, nodes can have different parents and children depending on the color of the thread being shown in the outline. Maybe 'green' would display as the documentation, with code and > narrative interspersed. > > Am I on the right track? > On exactly the right track. One *real* benefit comes to mind. In the new world it would be possible to "clone" just a node without including it's children. This is a frequently requested feature. For example, it would allow any node, all by itself, to be included in a documentation file. Following a discussion you and I had ages ago about documentation, one could even imagine the *body text* of a node changing depending on attribute. It's a little bizarre, but suppose that p.b (the node's text) represents, generally speaking, what we want to say on subject x. Well, the *actual* text might be subtly different in various documentation contexts. Attributes might be the way to alter that text. Yes, this raises the ui question about how to see some or all of the various versions of text. Do we want to split the body pane, for instance? This discovery is important because it raises so many new questions. Happily, I've calmed down considerably since yesterday afternoon :-) I am no hurry to change Leo's core. I shall not do so until I see a clear way of removing clones from my work flow. That hasn't happened yet. However, I do think I have resolved the question about whether each threaded "layer" will support clones or not. At the *implementation *level, the answer will be yes. There is no reason to alter Leo's code to get rid of clones, even if clones become almost an Easter Egg. But as a *thought experiment*, we definitely want to understand what could be done without clones. 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.
