On Fri, Jul 4, 2014 at 12:27 PM, Edward K. Ream <[email protected]> wrote:
> I think it would be good to set up a conference call between Kent, > Terry and myself to discuss this. There are soooo many questions I'd > like to ask and ideas to explore. 1. I'm seriously starting to wonder whether clones my be thought of as more plumbing than porcelain. 2. gnx's are all about identity, which is essential in plumbing (Python references are all about identity). But from the user's (porcelain) perspective, do we actually care about identity? I actually think not. 3. Are broken clone links all that serious? In plumbing, yes; in porcelain, no. It's not the identity of a node (it's gnx, who created it, and when), but its purpose. 4. Imo, Leo *must* soon support org mode file format. It's crazy not to: it's a standard. 5. Consider this ordering of external files: A. @auto: No (obvious) clone links. No user-defined outline structure. B. @org-mode: No clone links: User defined outline structure. C. @file: Clone links and user-defined outline structure. But if we don't care about identity (clone links), B and C are starting to look alike! 6. Getting back to point 3 above. Freeing ourselves from a rigid notion of identity could be *liberating*. I usually think of clones as focusing attention, or creating views. Well, why should identity (clones) be the main tool for that? It shouldn't be! And Terry's bookmarks show another way. So instead of thinking of views as being defined by sets of nodes with given identities, it would be better (more general) to think of views as sets of nodes defined in other ways. Such as: - Sets of nodes matching patterns patterns (searches) - Nodes matching *generalized unl's*. Indeed, our present notion of unl tries to duplicate the notion of identity, using other means, namely rigid sequences of headlines. But imo, we *never* really care about full paths when using unls. Instead, we are really thinking about relationships. Examples: - A top-level function foo in file spam.py. - A method x in class y in spam.py. - All subnodes of an organizer node z in spam.py. - All subnodes of the first @bookmarks node in spam.py. These suggest that we should treat unl's as patterns to be matched (somehow) against the nodes of an outline. Crucially, identity plays *no* part in either the matching *or* in our thinking. PyCharm, and probably other editors/IDE's, have used this notion of pattern matching to good effect. ===== Summary and further thoughts Clones will always be a fundamental part of Leo's core. I foresee absolutely no change to positions, vnodes, iterators, etc. We could create clones (as part of views) not as the result of gnx's (wherever they might be located, in external files, in uA's or in a db) but rather as the result of a searching/pattern-matching process. Such patterns could define @view nodes. The children of @view nodes could be (clones of) all nodes matching the pattern in the body of the @view node. Clones could break (the search may fail). This simply means that the @view node has no children. The generalized unl's in the @view node would remain for inspection and/or change. Generalizing unl's will provide search pattern. Think of all the ways search patterns can be generalized. XSLT, for example! Searches can conceptually be done when loading an external file, but could be deferred until an @view node is actually accessed. If patterns, not identity, define/create/generate clones, great things happen: 1. @org-mode becomes roughly the same as @file! 2. Clones can refer to nodes in @auto files. 3. We might even be able to create organizer nodes in @auto files. In short, not being tied to the identity of nodes frees ourselves to use all the power of searching and pattern matching to locate and define nodes. I think this is an earth-shaking development. Edward P.S. Leo's search commands could have an "add to present @view" checkbox that would add the generalized unl to a particular @view node. This would be an alternative to the clone-find-all command. EKR -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
