This is an extremely interesting discussion. I'm using Tags extensively and also combining Tags with Icons so I can visualize things in the main tree. One thing I keep wrestling with is an easy way to display just what I want to see (like a "filter") across the entire tree but still within the tree mode where I can make real-time changes.
Imagine a tree with People as nodes, and Sports as Tags (or, "attributes"), where some People are sub-nodes to other People because that is order in which I met them. I might want to view the tree of only those tagged "golf" to see a tree with that part of my world and quickly add a couple people that who golf but I forgot to add previously -- literally some "forest vs tree" thinking (sorry for the bad pun). I know this more of a use case than a technical description of how to do this, but wanted to chime in. Thanks to Edward and all for such thoughtful, evolutionary stewardship of Leo's core. -Richard On Monday, February 15, 2016 at 7:05:08 AM UTC-8, Edward K. Ream wrote: > > On Sun, Feb 14, 2016 at 3:27 PM, Jose Gonzalez <[email protected] > <javascript:>> wrote: > >> Could this "multi-graph" structure be a mechanism to implement version >> control in Leo? >> > > A > superb > question. > > My present opinion is that the multi-graph stuff will work in the deep > background. It doesn't seem directly relevant to the problems I have with > clones, but it's still early days. > > As you know, the fundamental data structure for Git and other version >> control systems is also a DAG. If, in addition to the existing tree >> representing the document structure, there is another tree defining the >> evolution in time of the document/each node, then Leo would be able to >> track the whole history of a project. >> > > This is something that Kent has been wanting for a long time. > > Here's one way. Each vnode could have an additional dict: keys would be, > per your suggestion, git sha1 keys(!), values would be the "contents" of > the node at that rev, say headline, body text and attributes. It's slick. > > Notice: the multi-graph isn't needed for this scheme. But the multi-graph > has clearly created a fertile environment for thinking such thoughts! > > To repeat. It is my present opinion that the multi-graph actually solves > none of the use-case issues I've been thinking about. But the multi-graph > is such a cool idea that it will stimulate all sorts of great things. > > 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.
