Discussion:
Leo reimagined: a tree/dag/view for every attribute!!!
(too old to reply)
Edward K. Ream
2016-02-11 23:12:19 UTC
Permalink
John Lunzer's recent remarks has triggered one of the biggest Aha's in
Leo's history, one that was totally unexpected until this afternoon.

Leo's fundamental data structure is a tree of nodes. More accurately, it
is a Directed Acyclic Graph or dag. Links in such a graph can point "down"
the tree, but never up, so there are no cycles. Leo's clones are well
defined just exactly because there are no cycles. Given a node, we know
precisely *and* intuitively which nodes are descendants. Because of clones,
a node may have more than one parent.

Here's the Aha. Imagine this data structure as being linked with *black*
thread. Now imagine another *completely independent* set of *red*
threads. The only requirement is that the links defined by the red threads
must *also* be a tree/dag. That is, there is *absolutely no* necessary
relationship between the red and black threads.

Now imagine that every Leo attribute creates its *own* sets of
links/threads. *We have a new view for every attribute.* Let's call such a
data structure a *multi-threaded tree/dag*. Trees might actually be enough,
but I'm not sure so I'll refer to tree/dag (tree or dag). *Important*: some
nodes may not have any thread running them for some colored threads
(attributes). That's just fine.

Alas, the term "multi-threaded data structure" is commonly used for data
structures that can be accessed by independently running threads. That's
not at all what I am talking about.

I am not aware of anything like this in graph theory. Could this be a truly
new idea? I really have no idea.

Of course, you could call the resulting structure a general graph, and
technically it is, but how the data structure will be used inside Leo is *very
*different. Instead of a single, unintuitive mess, we have a collection of
easily traversed trees/dags. *We instantly have an arbitrary dimensioned
graph*! Each color creates a new dimension. Of course, we only *see* one
dimension at a time, but attributes may be the *composition* of other
attributes (unions, intersections or other relations), so this is no real
restriction.

And listen to this. *It is astoundingly easy to create this multi-dag in
Leo*. At present, each vnode has a parents list and a children list. All
we have to do is replace these two lists by dictionaries whose keys are
attributes and whose values are the parents or children lists for those
attributes. Finally, we add Python properties shield the dictionary lookup
from the rest of Leo. We are talking about maybe 50 lines of code! As far
as the rest of Leo is concerned, vnodes *still* have parents and children
lists. The switcheroo happens totally invisibly, when the user wants to
see another view. The attribute changes and that changes what the vnode
dictionary/properties "deliver" to the rest of Leo.

To recap: What we see depends only on the attribute that defines the view.
This attribute determines what parents and children lists become active.
So easy. So very powerful.

Each *current view* will show only the nodes with the given attribute. To
repeat, attributes can be composed of other attributes, so in effect each
view can be associated with an *arbitrary set* of attributes. This is an
*astoundingly* general data structure.

The real challenge lies in assigning different colored links to nodes. I'm
still trying to wrap my thoughts around all of this.

As always with truly huge Ahas, it's already impossible to know exactly
what thoughts lead to it. As soon as the Aha happened, the world changed
so much that the past becomes hard to reconstruct. But for sure the
following factors were "in the air":

1. Most importantly, the consensus has been building among the usual
suspects that attributes are a more intuitive, and perhaps more powerful,
alternative to clones.

2. For the last year I have been trying to ignore the fact that sometimes
clones get in the way. This was the meaning of today's remark that "I love
clones, I hate clones".

3. John's remark about attributes and hoists certainly triggered the
avalanche.

*Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes
complexity. In particular, both hoists and chapters are a (mildly
successful) attempt to make clones do the work of attribute-based views. In
the new scheme, we simply re-thread nodes that we want to be part of the
new view.

*And notice*: when we require that views be made of clones we can *not*
change any parent/child relationships. But that constraint completely
disappears when we use attributes to define views.

*Summary*

This is one of the most momentous Aha's in Leo's history. It was completely
unexpected this morning. It is almost too easy to make it happen. I may do
it this evening.

There remain important user interface questions concerning how nodes get
assigned various colored threads, but I have faith that the result will be
truly amazing.

This Aha will have a huge number of happy consequences. Just for starters:

1. Searches can be limited to a single view (thread color). If we don't
use clones in a view, each search will find a node at most once. This will
erase my biggest pet peeve about Leo!

2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.

3. It will be *very easy* for attribute editors to show nodes having those
attributes in the most natural way *for that attribute* without being
constrained in any way by other organizations of the data. Yes, this is
really just a restatement of 2, but it's different in practice.

No way would this Aha have happened without the interesting conversations
that have taken place in the last few months. Well done, all of us!

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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
'Terry Brown' via leo-editor
2016-02-12 00:20:52 UTC
Permalink
Sounds very interesting. Might be worth a look at the backlinks plug-in, which provides a mechanism and gui for superimposing a general graph on the tree. Graphcanvas plug-in is just another gui for the same mechanism.

Bit entirely sure I follow the 'attribute' part vs nodes, and of course something more integral to Leo's core would be a lot more powerful than the backlinks overlay.

Also long ago I did demo navigation of a cyclic graph using a tree, not sure if that's relevant. Also recalling the sea of nodes idea that's surfaced periodically.

Interesting direction, for sure.
Cheers -Terry
Post by Edward K. Ream
John Lunzer's recent remarks has triggered one of the biggest Aha's in
Leo's history, one that was totally unexpected until this afternoon.
Leo's fundamental data structure is a tree of nodes. More accurately, it
is a Directed Acyclic Graph or dag. Links in such a graph can point "down"
the tree, but never up, so there are no cycles. Leo's clones are well
defined just exactly because there are no cycles. Given a node, we know
precisely *and* intuitively which nodes are descendants. Because of clones,
a node may have more than one parent.
Here's the Aha. Imagine this data structure as being linked with *black*
thread. Now imagine another *completely independent* set of *red*
threads. The only requirement is that the links defined by the red threads
must *also* be a tree/dag. That is, there is *absolutely no* necessary
relationship between the red and black threads.
Now imagine that every Leo attribute creates its *own* sets of
links/threads. *We have a new view for every attribute.* Let's call such a
data structure a *multi-threaded tree/dag*. Trees might actually be enough,
but I'm not sure so I'll refer to tree/dag (tree or dag). *Important*: some
nodes may not have any thread running them for some colored threads
(attributes). That's just fine.
Alas, the term "multi-threaded data structure" is commonly used for data
structures that can be accessed by independently running threads. That's
not at all what I am talking about.
I am not aware of anything like this in graph theory. Could this be a truly
new idea? I really have no idea.
Of course, you could call the resulting structure a general graph, and
technically it is, but how the data structure will be used inside Leo is *very
*different. Instead of a single, unintuitive mess, we have a collection of
easily traversed trees/dags. *We instantly have an arbitrary
dimensioned
graph*! Each color creates a new dimension. Of course, we only *see* one
dimension at a time, but attributes may be the *composition* of other
attributes (unions, intersections or other relations), so this is no real
restriction.
And listen to this. *It is astoundingly easy to create this multi-dag in
Leo*. At present, each vnode has a parents list and a children list.
All
we have to do is replace these two lists by dictionaries whose keys are
attributes and whose values are the parents or children lists for those
attributes. Finally, we add Python properties shield the dictionary lookup
from the rest of Leo. We are talking about maybe 50 lines of code! As far
as the rest of Leo is concerned, vnodes *still* have parents and children
lists. The switcheroo happens totally invisibly, when the user wants to
see another view. The attribute changes and that changes what the vnode
dictionary/properties "deliver" to the rest of Leo.
To recap: What we see depends only on the attribute that defines the view.
This attribute determines what parents and children lists become active.
So easy. So very powerful.
Each *current view* will show only the nodes with the given attribute. To
repeat, attributes can be composed of other attributes, so in effect each
view can be associated with an *arbitrary set* of attributes. This is an
*astoundingly* general data structure.
The real challenge lies in assigning different colored links to nodes. I'm
still trying to wrap my thoughts around all of this.
As always with truly huge Ahas, it's already impossible to know exactly
what thoughts lead to it. As soon as the Aha happened, the world changed
so much that the past becomes hard to reconstruct. But for sure the
1. Most importantly, the consensus has been building among the usual
suspects that attributes are a more intuitive, and perhaps more
powerful,
alternative to clones.
2. For the last year I have been trying to ignore the fact that
sometimes
clones get in the way. This was the meaning of today's remark that "I love
clones, I hate clones".
3. John's remark about attributes and hoists certainly triggered the
avalanche.
*Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes
complexity. In particular, both hoists and chapters are a (mildly
successful) attempt to make clones do the work of attribute-based views. In
the new scheme, we simply re-thread nodes that we want to be part of the
new view.
*And notice*: when we require that views be made of clones we can *not*
change any parent/child relationships. But that constraint completely
disappears when we use attributes to define views.
*Summary*
This is one of the most momentous Aha's in Leo's history. It was completely
unexpected this morning. It is almost too easy to make it happen. I may do
it this evening.
There remain important user interface questions concerning how nodes get
assigned various colored threads, but I have faith that the result will be
truly amazing.
1. Searches can be limited to a single view (thread color). If we don't
use clones in a view, each search will find a node at most once. This will
erase my biggest pet peeve about Leo!
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
3. It will be *very easy* for attribute editors to show nodes having those
attributes in the most natural way *for that attribute* without being
constrained in any way by other organizations of the data. Yes, this is
really just a restatement of 2, but it's different in practice.
No way would this Aha have happened without the interesting
conversations
that have taken place in the last few months. Well done, all of us!
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
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
'Terry Brown' via leo-editor
2016-02-12 02:01:05 UTC
Permalink
Post by 'Terry Brown' via leo-editor
Bit entirely sure I follow the 'attribute' part vs nodes, and of course
*Not* entirely, phone email autocomplete :-/
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Edward K. Ream
2016-02-12 11:49:08 UTC
Permalink
​​On Thu, Feb 11, 2016 at 6:20 PM, 'Terry Brown' via leo-editor <
leo-***@googlegroups.com> wrote:

Might be worth a look at the backlinks plug-in, which provides a mechanism
Post by 'Terry Brown' via leo-editor
and gui for superimposing a general graph on the tree. Graphcanvas plug-in
is just another gui for the same mechanism.
​As I said in the original posting, the new scheme won't be used as a
general graph.​
Post by 'Terry Brown' via leo-editor
Not ​
entirely sure I follow the 'attribute' part vs nodes,

​At the implementation level, v.parents and v.children ​get swapped in and
out depending on which attribute is in effect for the *display* of the
outline. The drawing code stays the same! It doesn't know about the
switcheroo.

​> ​
Also long ago I did demo navigation of a cyclic graph using a tree, not
sure if that's relevant.

​I think that's something different, because the new idea gives, in effect,
a set of layers (one per attribute). Each layer contains Leo's existing
tree structure.
Post by 'Terry Brown' via leo-editor
​
Also recalling the sea of nodes idea that's surfaced periodically.

​Thanks for reminding me of this!​ Iirc, this was B. H.'s (LeoUser's)
suggestion. At the time he made it, I had no idea what it meant. But the
Aha makes it perfectly clear. Yes, the "black" threading could be called a
preferred view, but it's just as valid to think of each node as being
*completely
independent* of all other nodes. Each node is an island in the sea. Each
node can participate in arbitrarily many threadings/ trees.

​> ​
Interesting direction, for sure.

​To repeat what I said to Kent, the question I am presently asking myself
is what my work flow would be in the new scheme. In some sense, I need a
prototype, but I think pencil and paper will suffice. In fact, I am
considering what keystrokes/commands I would use as an alternative to
Ctrl-` (clone), etc. No conclusions yet. I won't do anything until I am
*sure* that the new scheme actually simplifies Leo for all users, including
me.

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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Jacob Peck
2016-02-12 14:40:20 UTC
Permalink
Hi Edward,

Fascinating stuff. I'm unclear on one thing though -- what you mean by
'attribute'. Is this just some arbitrary, user-definable key that would
act as a name for a particular view/colored-thread?

UI would be of paramount importance in this scheme -- there's lots of
places visually and conceptually such a powerful idea could go terribly
wrong. If you hide all the information that isn't immediately relevant
(i.e., show only the black-thread DAG with no visual indication that
there are other threads available) then you can lose a coherent view of
the whole document. If instead you show all the info at all times, you
/will/ overload the user, and as a result turn even more people off of
Leo at first blush. A happy medium would be one active attribute, with
small visual hints that others exist, with some set of convenient
key-bindings to switch between them, list them, etc. I imagine a
combobox much like the Chapter control would help with this immensely.

One thing that comes to mind as being potentially tricky -- how does
saving external files work? Would the save command create all valid
files for all valid attributes/views, or would it save only the current
view? What if there are collisions -- i.e. multiple views creating the
same file with different contents -- which attribute would take priority?

I thought of a potential use case, if scripts were allowed to be created
in one view but called from another: the 'exec(g.findTestScript())'
trick wouldn't be required to include shared code nodes any more --
simply create a new view for each script pulling in the nodes you need.
In fact, this paradigm could extend to full projects, if flexible
enough! The ultimate in write-once coding.

I'm genuinely intrigued by this new development. Exciting times indeed.

-->Jake
Post by Edward K. Ream
​​On Thu, Feb 11, 2016 at 6:20 PM, 'Terry Brown' via leo-editor
Might be worth a look at the backlinks plug-in, which provides a
mechanism and gui for superimposing a general graph on the tree.
Graphcanvas plug-in is just another gui for the same mechanism.
​As I said in the original posting, the new scheme won't be used as a
general graph.​
Post by 'Terry Brown' via leo-editor
Not ​
entirely sure I follow the 'attribute' part vs nodes,
​At the implementation level, v.parents and v.children ​get swapped in
and out depending on which attribute is in effect for the /display/ of
the outline. The drawing code stays the same! It doesn't know about
the switcheroo.
​> ​
Also long ago I did demo navigation of a cyclic graph using a tree,
not sure if that's relevant.
​I think that's something different, because the new idea gives, in
effect, a set of layers (one per attribute). Each layer contains Leo's
existing tree structure.
Post by 'Terry Brown' via leo-editor
​
Also recalling the sea of nodes idea that's surfaced periodically.
​Thanks for reminding me of this!​ Iirc, this was B. H.'s (LeoUser's)
suggestion. At the time he made it, I had no idea what it meant. But
the Aha makes it perfectly clear. Yes, the "black" threading could be
called a preferred view, but it's just as valid to think of each node
as being /completely independent/ of all other nodes. Each node is an
island in the sea. Each node can participate in arbitrarily many
threadings/ trees.
​> ​
Interesting direction, for sure.
​To repeat what I said to Kent, the question I am presently asking
myself is what my work flow would be in the new scheme. In some
sense, I need a prototype, but I think pencil and paper will suffice.
In fact, I am considering what keystrokes/commands I would use as an
alternative to Ctrl-` (clone), etc. No conclusions yet. I won't do
anything until I am /sure/ that the new scheme actually simplifies Leo
for all users, including me.
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
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
'Terry Brown' via leo-editor
2016-02-12 15:22:45 UTC
Permalink
From: Jacob Peck <***@gmail.com>
To: leo-***@googlegroups.com
Sent: Friday, February 12, 2016 8:40 AM
Subject: Re: Leo reimagined: a tree/dag/view for every attribute!!!

Hi Edward,



Fascinating stuff.  I'm unclear on one thing though -- what you mean by 'attribute'.  Is this just some arbitrary, user-definable key that would act as a name for a particular view/colored-thread?

My take after Edward's last comment, is there's *one* new attribute, 'view_mode' or whatever, and a different set of connections between nodes for each *value* of that attribute. Values might be "base_tree", "scroll_bug", "todo", etc. depending on what you're trying to focus on.
Cheers -Terry


UI would be of paramount importance in this scheme -- there's lots of places visually and conceptually such a powerful idea could go terribly wrong.  If you hide all the information that isn't immediately relevant (i.e., show only the black-thread DAG with no visual indication that there are other threads available) then you can lose a coherent view of the whole document.  If instead you show all the info at all times, you will overload the user, and as a result turn even more people off of Leo at first blush.  A happy medium would be one active attribute, with small visual hints that others exist, with some set of convenient key-bindings to switch between them, list them, etc.  I imagine a combobox much like the Chapter control would help with this immensely.

One thing that comes to mind as being potentially tricky -- how does saving external files work?  Would the save command create all valid files for all valid attributes/views, or would it save only the current view?  What if there are collisions -- i.e. multiple views creating the same file with different contents -- which attribute would take priority?

I thought of a potential use case, if scripts were allowed to be created in one view but called from another: the 'exec(g.findTestScript())' trick wouldn't be required to include shared code nodes any more -- simply create a new view for each script pulling in the nodes you need.  In fact, this paradigm could extend to full projects, if flexible enough!  The ultimate in write-once coding.

I'm genuinely intrigued by this new development.  Exciting times indeed.

-->Jake

On 2/12/2016 6:49 AM, Edward K. Ream wrote:

​​On Thu, Feb 11, 2016 at 6:20 PM, 'Terry Brown' via leo-editor <leo-***@googlegroups.com> wrote:


Might be worth a look at the backlinks plug-in, which provides a mechanism and gui for superimposing a general graph on the tree. Graphcanvas plug-in is just another gui for the same mechanism.


​As I said in the original posting, the new scheme won't be used as a general graph.​  
Not ​ entirely sure I follow the 'attribute' part vs nodes,
​At the implementation level, v.parents and v.children ​get swapped in and out depending on which attribute is in effect for the display of the outline. The drawing code stays the same! It doesn't know about the switcheroo.
 
​> ​ Also long ago I did demo navigation of a cyclic graph using a tree, not sure if that's relevant.

​I think that's something different, because the new idea gives, in effect, a set of layers (one per attribute). Each layer contains Leo's existing tree structure.
​ Also recalling the sea of nodes idea that's surfaced periodically.
​Thanks for reminding me of this!​ Iirc, this was B. H.'s (LeoUser's) suggestion. At the time he made it, I had no idea what it meant. But the Aha makes it perfectly clear.  Yes, the "black" threading could be called a preferred view, but it's just as valid to think of each node as being completely independent of all other nodes. Each node is an island in the sea. Each node can participate in arbitrarily many threadings/ trees.

​> ​ Interesting direction, for sure.

​To repeat what I said to Kent, the question I am presently asking myself is what my work flow would be in the new scheme.  In some sense, I need a prototype, but I think pencil and paper will suffice.  In fact, I am considering what keystrokes/commands I would use as an alternative to Ctrl-` (clone), etc.  No conclusions yet. I won't do anything until I am sure that the new scheme actually simplifies Leo for all users, including me.

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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2016-02-12 18:38:26 UTC
Permalink
Well, I'm certainly happy to have been part of the conversation.

On Thursday, February 11, 2016 at 6:12:20 PM UTC-5, Edward K. Ream wrote:

I see these three statements as fundamental to the data structure:

*Important*: some nodes may not have any thread running them for some
colored threads (attributes). That's just fine.
The only requirement is that the links defined by the red threads must
*also* be a tree/dag.
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
I'm trying to really understand this.

The way it works now is there is an "underlying" directed acyclic graph
structure *viewed as a tree*. That part is important. We could say that
right now we only have access to a single view I'll call the "classic"
view, with no way to modify the view. Classic referring to the "old" Leo
where every node could have only one attribute. An unacknowledged unnamed
attribute, but there nonetheless. Clones don't create views or use
attributes at all, a clone is merely a node with more than one parent.
Because we're using a tree to view the graph the only way to view a node
with more than one parent is to show that node twice on the tree. This
creates a sort of "pseudo-view" because clones result in showing redundant
information in the same tree. It is the same tree because there is always
an invisible root node which all other nodes descend from.

Now I'm struggling to understand this new data structure based on your
statements. To start, any viewing of the data structure must be done
through "views". Let's simplify things and say that the fundamental element
in this structure is a node and a single node could have a headline, a
body, and a list of attributes. Lets say a node cannot have children. To
keep things simple things lets start with a situation where you have five
nodes without a defined body/headline/attributes. If these nodes have no
attributes there is no way to view and in effect it appears to the user
that they do no exist because he/she can not access them. So I believe your
first statement is wrong, every node needs at least one attribute.

Keeping with this simplest case the next step is to add an attribute to
each. We could add a different attribute to each which would provide five
views. Or we could add the same single attribute to each which would create
one view. In this latter case of a single attribute what the user would see
is a flat list of five nodes. Because our fundamental element is a node and
we haven't defined a way to associate nodes with each other other than with
an attribute a flat list is the best we can get. Not very interesting yet.

To make this a little more interesting let us expand the fundamental
element to have a simple tree structure (for now let's leave clones out of
this, every node in the tree can have only one parent). Without attributes
again there is no view. In the simplest case the root of each tree could be
given an attribute and children would inherit that attribute. If all trees
had the same attribute we're starting to get close to what Leo is right
now.

Where do threads fit into this? Attributes by themselves do not imply
membership to a thread. Attributes do not imply any parent-child
relationship. Attributes only collect trees into a list to be viewed. And
in fact at this point this is almost exactly what I described in the
previous forum thread as "hoisting a collection of nodes". In that case
nodes as trees. For simplicity a possible restriction there could be the
same as above, marking a node with an attribute would pull in the whole
sub-tree and subsequent nodes couldn't be marked with the same attribute,
this would prevent a sort of "pseudo-clone" being viewed in a hoisted list
of trees.

In fact from this build up it appears that attributes have nothing to do
with threads. Threads have to include parent-child relationship between
nodes. And based on your description below it seems to disregard any
structure underlying trees of nodes.

The only requirement is that the links defined by the red threads must
*also* be a tree/dag.
Well that's as far as my brain will take me today. Starting to really lose
my grip on the concept. Don't doubt it at all just looking for some more
detailed clarifications.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Jacob Peck
2016-02-12 19:14:32 UTC
Permalink
Post by john lunzer
Well, I'm certainly happy to have been part of the conversation.
*Important*: some nodes may not have any thread running them for
some colored threads (attributes). That's just fine.
The only requirement is that the links defined by the red threads
must /also/ be a tree/dag.
2. Every view (attribute) can define/create its own set of
parent/child relationships, independently of all other views.
Afaik, no other data structure is this flexible while still
remaining intuitive.
I'm trying to really understand this.
The way it works now is there is an "underlying" directed acyclic
graph structure /viewed as a tree/. That part is important. We could
say that right now we only have access to a single view I'll call the
"classic" view, with no way to modify the view. Classic referring to
the "old" Leo where every node could have only one attribute. An
unacknowledged unnamed attribute, but there nonetheless. Clones don't
create views or use attributes at all, a clone is merely a node with
more than one parent. Because we're using a tree to view the graph the
only way to view a node with more than one parent is to show that node
twice on the tree. This creates a sort of "pseudo-view" because clones
result in showing redundant information in the same tree. It is the
same tree because there is always an invisible root node which all
other nodes descend from.
Now I'm struggling to understand this new data structure based on your
statements. To start, any viewing of the data structure must be done
through "views". Let's simplify things and say that the fundamental
element in this structure is a node and a single node could have a
headline, a body, and a list of attributes. Lets say a node cannot
have children. To keep things simple things lets start with a
situation where you have five nodes without a defined
body/headline/attributes. If these nodes have no attributes there is
no way to view and in effect it appears to the user that they do no
exist because he/she can not access them. So I believe your first
statement is wrong, every node needs at least one attribute.
I might be stepping on Edward's toes here, but I don't think nodes with
*no* attributes would be viable in his vision. I think every node would
at least need to be connected to the 'master' view. At least, that's
the only sane thing I can come up with. And if the user only ever uses
the 'master' view for storage, and never interacts with it outside of
that, then we'd never have completely invisible nodes.
Post by john lunzer
Keeping with this simplest case the next step is to add an attribute
to each. We could add a different attribute to each which would
provide five views. Or we could add the same single attribute to each
which would create one view. In this latter case of a single attribute
what the user would see is a flat list of five nodes. Because our
fundamental element is a node and we haven't defined a way to
associate nodes with each other other than with an attribute a flat
list is the best we can get. Not very interesting yet.
I think the interesting part is how we get from a flat list of nodes to
something resembling structure. Perhaps once we add an attribute to
these five nodes, and we switch to that view, any restructuring we do
inside that view is restricted to that view only. Then it just becomes
a matter of using the usual organizational commands/keyboard
shortcuts/API calls. Easy peasy :)
Post by john lunzer
To make this a little more interesting let us expand the fundamental
element to have a simple tree structure (for now let's leave clones
out of this, every node in the tree can have only one parent). Without
attributes again there is no view. In the simplest case the root of
each tree could be given an attribute and children would inherit that
attribute. If all trees had the same attribute we're starting to get
close to what Leo is right now.
Where do threads fit into this? Attributes by themselves do not imply
membership to a thread. Attributes do not imply any parent-child
relationship. Attributes only collect trees into a list to be viewed.
And in fact at this point this is almost exactly what I described in
the previous forum thread as "hoisting a collection of nodes". In that
case nodes as trees. For simplicity a possible restriction there could
be the same as above, marking a node with an attribute would pull in
the whole sub-tree and subsequent nodes couldn't be marked with the
same attribute, this would prevent a sort of "pseudo-clone" being
viewed in a hoisted list of trees.
In fact from this build up it appears that attributes have nothing to
do with threads. Threads have to include parent-child relationship
between nodes. And based on your description below it seems to
disregard any structure underlying trees of nodes.
The only requirement is that the links defined by the red threads
must /also/ be a tree/dag.
To be honest, I think the decoupling here is key. There should probably
be convenience commands to copy tree structure from one view/attribute
to another, but that's an implementation detail -- the flexibility
allowed by not imposing these restrictions trumps, in my opinion, any
inconveniences.
Post by john lunzer
Well that's as far as my brain will take me today. Starting to really
lose my grip on the concept. Don't doubt it at all just looking for
some more detailed clarifications.
Me too! Excited to see where this goes.

-->Jake
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2016-02-12 19:23:26 UTC
Permalink
Thanks for your reaction, very much agree about all nodes have at least one
attribute. Really just trying to work through it and hoping to further
incite Edward's brain to help with any clarification, hopefully pointing
out where I'd gone wrong in my buildup.
Post by john lunzer
Well, I'm certainly happy to have been part of the conversation.
*Important*: some nodes may not have any thread running them for some
colored threads (attributes). That's just fine.
The only requirement is that the links defined by the red threads must
*also* be a tree/dag.
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
I'm trying to really understand this.
The way it works now is there is an "underlying" directed acyclic graph
structure *viewed as a tree*. That part is important. We could say that
right now we only have access to a single view I'll call the "classic"
view, with no way to modify the view. Classic referring to the "old" Leo
where every node could have only one attribute. An unacknowledged unnamed
attribute, but there nonetheless. Clones don't create views or use
attributes at all, a clone is merely a node with more than one parent.
Because we're using a tree to view the graph the only way to view a node
with more than one parent is to show that node twice on the tree. This
creates a sort of "pseudo-view" because clones result in showing redundant
information in the same tree. It is the same tree because there is always
an invisible root node which all other nodes descend from.
Now I'm struggling to understand this new data structure based on your
statements. To start, any viewing of the data structure must be done
through "views". Let's simplify things and say that the fundamental element
in this structure is a node and a single node could have a headline, a
body, and a list of attributes. Lets say a node cannot have children. To
keep things simple things lets start with a situation where you have five
nodes without a defined body/headline/attributes. If these nodes have no
attributes there is no way to view and in effect it appears to the user
that they do no exist because he/she can not access them. So I believe your
first statement is wrong, every node needs at least one attribute.
I might be stepping on Edward's toes here, but I don't think nodes with
*no* attributes would be viable in his vision. I think every node would at
least need to be connected to the 'master' view. At least, that's the only
sane thing I can come up with. And if the user only ever uses the 'master'
view for storage, and never interacts with it outside of that, then we'd
never have completely invisible nodes.
Keeping with this simplest case the next step is to add an attribute to
each. We could add a different attribute to each which would provide five
views. Or we could add the same single attribute to each which would create
one view. In this latter case of a single attribute what the user would see
is a flat list of five nodes. Because our fundamental element is a node and
we haven't defined a way to associate nodes with each other other than with
an attribute a flat list is the best we can get. Not very interesting yet.
I think the interesting part is how we get from a flat list of nodes to
something resembling structure. Perhaps once we add an attribute to these
five nodes, and we switch to that view, any restructuring we do inside that
view is restricted to that view only. Then it just becomes a matter of
using the usual organizational commands/keyboard shortcuts/API calls. Easy
peasy :)
To make this a little more interesting let us expand the fundamental
element to have a simple tree structure (for now let's leave clones out of
this, every node in the tree can have only one parent). Without attributes
again there is no view. In the simplest case the root of each tree could be
given an attribute and children would inherit that attribute. If all trees
had the same attribute we're starting to get close to what Leo is right
now.
Where do threads fit into this? Attributes by themselves do not imply
membership to a thread. Attributes do not imply any parent-child
relationship. Attributes only collect trees into a list to be viewed. And
in fact at this point this is almost exactly what I described in the
previous forum thread as "hoisting a collection of nodes". In that case
nodes as trees. For simplicity a possible restriction there could be the
same as above, marking a node with an attribute would pull in the whole
sub-tree and subsequent nodes couldn't be marked with the same attribute,
this would prevent a sort of "pseudo-clone" being viewed in a hoisted list
of trees.
In fact from this build up it appears that attributes have nothing to do
with threads. Threads have to include parent-child relationship between
nodes. And based on your description below it seems to disregard any
structure underlying trees of nodes.
The only requirement is that the links defined by the red threads must
*also* be a tree/dag.
To be honest, I think the decoupling here is key. There should probably
be convenience commands to copy tree structure from one view/attribute to
another, but that's an implementation detail -- the flexibility allowed by
not imposing these restrictions trumps, in my opinion, any inconveniences.
Well that's as far as my brain will take me today. Starting to really lose
my grip on the concept. Don't doubt it at all just looking for some more
detailed clarifications.
Me too! Excited to see where this goes.
-->Jake
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2016-02-13 15:36:54 UTC
Permalink
Don, thanks for taking the abstraction back a step further.

Having thought about it again there is another fundamental element to the
data structure. Links, which describe who is interacting with who, or in
the node sense since the relationships can only go down, a one directional
edge (in graph theory terminology). In that case a "thread" would be a
collection of edges which share common nodes, directly or indirectly. My
understanding is that nodes themselves wouldn't necessarily need attributes
at all, though it might make sense for them to! If a view is simply a tree
visualization of a thread then it would be enough for the edges to have the
attributes.
In effect, consider starting with a bunch of entities, with no particular
structure relating them to each other. (I don't say "nodes", because that
already implies a structure.) For example, imagine a community of people,
each an individual, but who interact with each other in various ways, and
are related to each other in various contexts (family, employment, sports
league, ...).
Now, we can look at this bunch in many different ways: family relation,
usage for a particular purpose, etc. Each way is then represented by an
attribute. (I agree that this isn't a particularly good term for it; how
about "view structure" -- awkward, but gets at the concept.)
I think, though, the "love clones, hate clones" problem may well arise
here, if the user isn't clear and fairly well disciplined in
conceptualizing views. (And of course new views will arise over time, view
may change, and various views may interact in strange ways: "He's my boss
at work, but my son at home!") I can imagine needing a view structure to
organize one's views...
Don
​​On Thu, Feb 11, 2016 at 6:20 PM, 'Terry Brown' via leo-editor <
Might be worth a look at the backlinks plug-in, which provides a mechanism
Post by 'Terry Brown' via leo-editor
and gui for superimposing a general graph on the tree. Graphcanvas plug-in
is just another gui for the same mechanism.
​As I said in the original posting, the new scheme won't be used as a
general graph.​
Post by 'Terry Brown' via leo-editor
Not ​
entirely sure I follow the 'attribute' part vs nodes,
​At the implementation level, v.parents and v.children ​get swapped in and
out depending on which attribute is in effect for the *display* of the
outline. The drawing code stays the same! It doesn't know about the
switcheroo.
​> ​
Also long ago I did demo navigation of a cyclic graph using a tree, not
sure if that's relevant.
​I think that's something different, because the new idea gives, in
effect, a set of layers (one per attribute). Each layer contains Leo's
existing tree structure.
Post by 'Terry Brown' via leo-editor
​
Also recalling the sea of nodes idea that's surfaced periodically.
​Thanks for reminding me of this!​ Iirc, this was B. H.'s (LeoUser's)
suggestion. At the time he made it, I had no idea what it meant. But the
Aha makes it perfectly clear. Yes, the "black" threading could be called a
preferred view, but it's just as valid to think of each node as being *completely
independent* of all other nodes. Each node is an island in the sea. Each
node can participate in arbitrarily many threadings/ trees.
​> ​
Interesting direction, for sure.
​To repeat what I said to Kent, the question I am presently asking myself
is what my work flow would be in the new scheme. In some sense, I need a
prototype, but I think pencil and paper will suffice. In fact, I am
considering what keystrokes/commands I would use as an alternative to
Ctrl-` (clone), etc. No conclusions yet. I won't do anything until I am
*sure* that the new scheme actually simplifies Leo for all users,
including me.
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
<javascript:>.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Edward K. Ream
2016-02-15 14:54:59 UTC
Permalink
On Sat, Feb 13, 2016 at 9:27 PM, Don Dwiggins

I
​> ​
t might be useful to think of "intrinsic" vs. "extrinsic" attributes.

​An interesting distinction. Apparently, it's pretty important in
thermodynamics ;-)
​
An attribute that is intrinsic to an item (e.g., a person's birthdate)
might be best represented directly as an attribute of the person (unless a
date is treated as an item in its own right).

​This is going to take us into database theory. That's fine with me. The
immediate question is whether there are *any* intrinsic attributes,
especially when versioning of various flavors is thrown in.

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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Kent Tenney
2016-02-12 01:03:08 UTC
Permalink
I'm trying to see the use case.
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.

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.

Maybe 'green' would display as the documentation, with code and
narrative interspersed.

Am I on the right track?

Thanks,
Kent
John Lunzer's recent remarks has triggered one of the biggest Aha's in Leo's
history, one that was totally unexpected until this afternoon.
Leo's fundamental data structure is a tree of nodes. More accurately, it is
a Directed Acyclic Graph or dag. Links in such a graph can point "down" the
tree, but never up, so there are no cycles. Leo's clones are well defined
just exactly because there are no cycles. Given a node, we know precisely
and intuitively which nodes are descendants. Because of clones, a node may
have more than one parent.
Here's the Aha. Imagine this data structure as being linked with black
thread. Now imagine another completely independent set of red threads. The
only requirement is that the links defined by the red threads must also be a
tree/dag. That is, there is absolutely no necessary relationship between the
red and black threads.
Now imagine that every Leo attribute creates its own sets of links/threads.
We have a new view for every attribute. Let's call such a data structure a
multi-threaded tree/dag. Trees might actually be enough, but I'm not sure so
I'll refer to tree/dag (tree or dag). Important: some nodes may not have any
thread running them for some colored threads (attributes). That's just
fine.
Alas, the term "multi-threaded data structure" is commonly used for data
structures that can be accessed by independently running threads. That's not
at all what I am talking about.
I am not aware of anything like this in graph theory. Could this be a truly
new idea? I really have no idea.
Of course, you could call the resulting structure a general graph, and
technically it is, but how the data structure will be used inside Leo is
very different. Instead of a single, unintuitive mess, we have a collection
of easily traversed trees/dags. We instantly have an arbitrary dimensioned
graph! Each color creates a new dimension. Of course, we only see one
dimension at a time, but attributes may be the composition of other
attributes (unions, intersections or other relations), so this is no real
restriction.
And listen to this. It is astoundingly easy to create this multi-dag in
Leo. At present, each vnode has a parents list and a children list. All we
have to do is replace these two lists by dictionaries whose keys are
attributes and whose values are the parents or children lists for those
attributes. Finally, we add Python properties shield the dictionary lookup
from the rest of Leo. We are talking about maybe 50 lines of code! As far
as the rest of Leo is concerned, vnodes still have parents and children
lists. The switcheroo happens totally invisibly, when the user wants to see
another view. The attribute changes and that changes what the vnode
dictionary/properties "deliver" to the rest of Leo.
To recap: What we see depends only on the attribute that defines the view.
This attribute determines what parents and children lists become active. So
easy. So very powerful.
Each current view will show only the nodes with the given attribute. To
repeat, attributes can be composed of other attributes, so in effect each
view can be associated with an arbitrary set of attributes. This is an
astoundingly general data structure.
The real challenge lies in assigning different colored links to nodes. I'm
still trying to wrap my thoughts around all of this.
As always with truly huge Ahas, it's already impossible to know exactly what
thoughts lead to it. As soon as the Aha happened, the world changed so much
that the past becomes hard to reconstruct. But for sure the following
1. Most importantly, the consensus has been building among the usual
suspects that attributes are a more intuitive, and perhaps more powerful,
alternative to clones.
2. For the last year I have been trying to ignore the fact that sometimes
clones get in the way. This was the meaning of today's remark that "I love
clones, I hate clones".
3. John's remark about attributes and hoists certainly triggered the
avalanche.
Notice: multi-threaded tree/dags collapse a lot of behind-the scenes
complexity. In particular, both hoists and chapters are a (mildly
successful) attempt to make clones do the work of attribute-based views. In
the new scheme, we simply re-thread nodes that we want to be part of the new
view.
And notice: when we require that views be made of clones we can not change
any parent/child relationships. But that constraint completely disappears
when we use attributes to define views.
Summary
This is one of the most momentous Aha's in Leo's history. It was completely
unexpected this morning. It is almost too easy to make it happen. I may do
it this evening.
There remain important user interface questions concerning how nodes get
assigned various colored threads, but I have faith that the result will be
truly amazing.
1. Searches can be limited to a single view (thread color). If we don't use
clones in a view, each search will find a node at most once. This will erase
my biggest pet peeve about Leo!
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
3. It will be very easy for attribute editors to show nodes having those
attributes in the most natural way for that attribute without being
constrained in any way by other organizations of the data. Yes, this is
really just a restatement of 2, but it's different in practice.
No way would this Aha have happened without the interesting conversations
that have taken place in the last few months. Well done, all of us!
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
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Edward K. Ream
2016-02-12 11:34:08 UTC
Permalink
​​
Post by Kent Tenney
I'm trying to see the use case.
​So am I ;-)
​
Post by Kent Tenney
I know you use clones to gather scattered bits which are relevant
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.​
Post by Kent Tenney
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
Post by Kent Tenney
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Jose Gonzalez
2016-02-14 21:27:49 UTC
Permalink
Could this "multi-graph" structure be a mechanism to implement version
control in Leo? 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 could be a good foundation for collaborative document edition (merging
modifications on the same Leo document by multiple users), which would make
Leo even more powerful as a distributed tool for knowledge base management.

If the functionality can be implemented in such a way that the new "history
tree" can be fully mapped on top of an existing version control system such
as git (i.e. mapping each edge -representing the transition from a
particular version of a node to a newer one- to individual blobs in git
commits), then Leo could probably reuse many of the existing tools/concepts
from version control systems: diff visualization, synchronization between
users (i.e. pull requests, remotes), tree management, etc

Just my 2 cents
Jose
Post by Edward K. Ream
John Lunzer's recent remarks has triggered one of the biggest Aha's in
Leo's history, one that was totally unexpected until this afternoon.
Leo's fundamental data structure is a tree of nodes. More accurately, it
is a Directed Acyclic Graph or dag. Links in such a graph can point "down"
the tree, but never up, so there are no cycles. Leo's clones are well
defined just exactly because there are no cycles. Given a node, we know
precisely *and* intuitively which nodes are descendants. Because of
clones, a node may have more than one parent.
Here's the Aha. Imagine this data structure as being linked with *black*
thread. Now imagine another *completely independent* set of *red*
threads. The only requirement is that the links defined by the red threads
must *also* be a tree/dag. That is, there is *absolutely no* necessary
relationship between the red and black threads.
Now imagine that every Leo attribute creates its *own* sets of
links/threads. *We have a new view for every attribute.* Let's call such
a data structure a *multi-threaded tree/dag*. Trees might actually be
enough, but I'm not sure so I'll refer to tree/dag (tree or dag).
*Important*: some nodes may not have any thread running them for some
colored threads (attributes). That's just fine.
Alas, the term "multi-threaded data structure" is commonly used for data
structures that can be accessed by independently running threads. That's
not at all what I am talking about.
I am not aware of anything like this in graph theory. Could this be a
truly new idea? I really have no idea.
Of course, you could call the resulting structure a general graph, and
technically it is, but how the data structure will be used inside Leo is *very
*different. Instead of a single, unintuitive mess, we have a collection
of easily traversed trees/dags. *We instantly have an arbitrary
dimensioned graph*! Each color creates a new dimension. Of course, we
only *see* one dimension at a time, but attributes may be the
*composition* of other attributes (unions, intersections or other
relations), so this is no real restriction.
And listen to this. *It is astoundingly easy to create this multi-dag in
Leo*. At present, each vnode has a parents list and a children list.
All we have to do is replace these two lists by dictionaries whose keys are
attributes and whose values are the parents or children lists for those
attributes. Finally, we add Python properties shield the dictionary lookup
from the rest of Leo. We are talking about maybe 50 lines of code! As far
as the rest of Leo is concerned, vnodes *still* have parents and children
lists. The switcheroo happens totally invisibly, when the user wants to
see another view. The attribute changes and that changes what the vnode
dictionary/properties "deliver" to the rest of Leo.
To recap: What we see depends only on the attribute that defines the
view. This attribute determines what parents and children lists become
active. So easy. So very powerful.
Each *current view* will show only the nodes with the given attribute. To
repeat, attributes can be composed of other attributes, so in effect each
view can be associated with an *arbitrary set* of attributes. This is an
*astoundingly* general data structure.
The real challenge lies in assigning different colored links to nodes. I'm
still trying to wrap my thoughts around all of this.
As always with truly huge Ahas, it's already impossible to know exactly
what thoughts lead to it. As soon as the Aha happened, the world changed
so much that the past becomes hard to reconstruct. But for sure the
1. Most importantly, the consensus has been building among the usual
suspects that attributes are a more intuitive, and perhaps more powerful,
alternative to clones.
2. For the last year I have been trying to ignore the fact that sometimes
clones get in the way. This was the meaning of today's remark that "I love
clones, I hate clones".
3. John's remark about attributes and hoists certainly triggered the
avalanche.
*Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes
complexity. In particular, both hoists and chapters are a (mildly
successful) attempt to make clones do the work of attribute-based views. In
the new scheme, we simply re-thread nodes that we want to be part of the
new view.
*And notice*: when we require that views be made of clones we can *not*
change any parent/child relationships. But that constraint completely
disappears when we use attributes to define views.
*Summary*
This is one of the most momentous Aha's in Leo's history. It was
completely unexpected this morning. It is almost too easy to make it
happen. I may do it this evening.
There remain important user interface questions concerning how nodes get
assigned various colored threads, but I have faith that the result will be
truly amazing.
1. Searches can be limited to a single view (thread color). If we don't
use clones in a view, each search will find a node at most once. This will
erase my biggest pet peeve about Leo!
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
3. It will be *very easy* for attribute editors to show nodes having
those attributes in the most natural way *for that attribute* without
being constrained in any way by other organizations of the data. Yes, this
is really just a restatement of 2, but it's different in practice.
No way would this Aha have happened without the interesting conversations
that have taken place in the last few months. Well done, all of us!
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Edward K. Ream
2016-02-15 15:05:07 UTC
Permalink
Post by Jose Gonzalez
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
Post by Jose Gonzalez
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Conor White-Sullivan
2016-06-01 07:07:59 UTC
Permalink
This is amazing to come across.

I discovered Leo today after scouring the web trying to find some UI where
people were merging trees to create this a multi-dimensional dag, as you
describe. Totally in love with what you're doing.

I also had the realization recently that layering trees to form a graph
could be incredibly powerful

Here's the UI I built this weekend to get started


<Loading Image...>


Now just have to figure out a Clojure workflow and I'll be using your DAG
editor to build my graph editor ;)
Post by Edward K. Ream
John Lunzer's recent remarks has triggered one of the biggest Aha's in
Leo's history, one that was totally unexpected until this afternoon.
Leo's fundamental data structure is a tree of nodes. More accurately, it
is a Directed Acyclic Graph or dag. Links in such a graph can point "down"
the tree, but never up, so there are no cycles. Leo's clones are well
defined just exactly because there are no cycles. Given a node, we know
precisely *and* intuitively which nodes are descendants. Because of
clones, a node may have more than one parent.
Here's the Aha. Imagine this data structure as being linked with *black*
thread. Now imagine another *completely independent* set of *red*
threads. The only requirement is that the links defined by the red threads
must *also* be a tree/dag. That is, there is *absolutely no* necessary
relationship between the red and black threads.
Now imagine that every Leo attribute creates its *own* sets of
links/threads. *We have a new view for every attribute.* Let's call such
a data structure a *multi-threaded tree/dag*. Trees might actually be
enough, but I'm not sure so I'll refer to tree/dag (tree or dag).
*Important*: some nodes may not have any thread running them for some
colored threads (attributes). That's just fine.
Alas, the term "multi-threaded data structure" is commonly used for data
structures that can be accessed by independently running threads. That's
not at all what I am talking about.
I am not aware of anything like this in graph theory. Could this be a
truly new idea? I really have no idea.
Of course, you could call the resulting structure a general graph, and
technically it is, but how the data structure will be used inside Leo is *very
*different. Instead of a single, unintuitive mess, we have a collection
of easily traversed trees/dags. *We instantly have an arbitrary
dimensioned graph*! Each color creates a new dimension. Of course, we
only *see* one dimension at a time, but attributes may be the
*composition* of other attributes (unions, intersections or other
relations), so this is no real restriction.
And listen to this. *It is astoundingly easy to create this multi-dag in
Leo*. At present, each vnode has a parents list and a children list.
All we have to do is replace these two lists by dictionaries whose keys are
attributes and whose values are the parents or children lists for those
attributes. Finally, we add Python properties shield the dictionary lookup
from the rest of Leo. We are talking about maybe 50 lines of code! As far
as the rest of Leo is concerned, vnodes *still* have parents and children
lists. The switcheroo happens totally invisibly, when the user wants to
see another view. The attribute changes and that changes what the vnode
dictionary/properties "deliver" to the rest of Leo.
To recap: What we see depends only on the attribute that defines the
view. This attribute determines what parents and children lists become
active. So easy. So very powerful.
Each *current view* will show only the nodes with the given attribute. To
repeat, attributes can be composed of other attributes, so in effect each
view can be associated with an *arbitrary set* of attributes. This is an
*astoundingly* general data structure.
The real challenge lies in assigning different colored links to nodes. I'm
still trying to wrap my thoughts around all of this.
As always with truly huge Ahas, it's already impossible to know exactly
what thoughts lead to it. As soon as the Aha happened, the world changed
so much that the past becomes hard to reconstruct. But for sure the
1. Most importantly, the consensus has been building among the usual
suspects that attributes are a more intuitive, and perhaps more powerful,
alternative to clones.
2. For the last year I have been trying to ignore the fact that sometimes
clones get in the way. This was the meaning of today's remark that "I love
clones, I hate clones".
3. John's remark about attributes and hoists certainly triggered the
avalanche.
*Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes
complexity. In particular, both hoists and chapters are a (mildly
successful) attempt to make clones do the work of attribute-based views. In
the new scheme, we simply re-thread nodes that we want to be part of the
new view.
*And notice*: when we require that views be made of clones we can *not*
change any parent/child relationships. But that constraint completely
disappears when we use attributes to define views.
*Summary*
This is one of the most momentous Aha's in Leo's history. It was
completely unexpected this morning. It is almost too easy to make it
happen. I may do it this evening.
There remain important user interface questions concerning how nodes get
assigned various colored threads, but I have faith that the result will be
truly amazing.
1. Searches can be limited to a single view (thread color). If we don't
use clones in a view, each search will find a node at most once. This will
erase my biggest pet peeve about Leo!
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
3. It will be *very easy* for attribute editors to show nodes having
those attributes in the most natural way *for that attribute* without
being constrained in any way by other organizations of the data. Yes, this
is really just a restatement of 2, but it's different in practice.
No way would this Aha have happened without the interesting conversations
that have taken place in the last few months. Well done, all of us!
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
john lunzer
2016-06-01 11:57:17 UTC
Permalink
That is pretty rad, thanks for sharing!
Post by Conor White-Sullivan
This is amazing to come across.
I discovered Leo today after scouring the web trying to find some UI where
people were merging trees to create this a multi-dimensional dag, as you
describe. Totally in love with what you're doing.
I also had the realization recently that layering trees to form a graph
could be incredibly powerful
Here's the UI I built this weekend to get started
<https://lh3.googleusercontent.com/-T_L5LZZPBhM/V06JBKAtnQI/AAAAAAAAAb0/OdRt_KcVOTonmv6KDlL2eki87A6KKwp-QCLcB/s1600/treedom2.gif>
Now just have to figure out a Clojure workflow and I'll be using your DAG
editor to build my graph editor ;)
Post by Edward K. Ream
John Lunzer's recent remarks has triggered one of the biggest Aha's in
Leo's history, one that was totally unexpected until this afternoon.
Leo's fundamental data structure is a tree of nodes. More accurately, it
is a Directed Acyclic Graph or dag. Links in such a graph can point "down"
the tree, but never up, so there are no cycles. Leo's clones are well
defined just exactly because there are no cycles. Given a node, we know
precisely *and* intuitively which nodes are descendants. Because of
clones, a node may have more than one parent.
Here's the Aha. Imagine this data structure as being linked with *black*
thread. Now imagine another *completely independent* set of *red*
threads. The only requirement is that the links defined by the red threads
must *also* be a tree/dag. That is, there is *absolutely no* necessary
relationship between the red and black threads.
Now imagine that every Leo attribute creates its *own* sets of
links/threads. *We have a new view for every attribute.* Let's call
such a data structure a *multi-threaded tree/dag*. Trees might actually
be enough, but I'm not sure so I'll refer to tree/dag (tree or dag).
*Important*: some nodes may not have any thread running them for some
colored threads (attributes). That's just fine.
Alas, the term "multi-threaded data structure" is commonly used for data
structures that can be accessed by independently running threads. That's
not at all what I am talking about.
I am not aware of anything like this in graph theory. Could this be a
truly new idea? I really have no idea.
Of course, you could call the resulting structure a general graph, and
technically it is, but how the data structure will be used inside Leo is *very
*different. Instead of a single, unintuitive mess, we have a collection
of easily traversed trees/dags. *We instantly have an arbitrary
dimensioned graph*! Each color creates a new dimension. Of course, we
only *see* one dimension at a time, but attributes may be the
*composition* of other attributes (unions, intersections or other
relations), so this is no real restriction.
And listen to this. *It is astoundingly easy to create this multi-dag
in Leo*. At present, each vnode has a parents list and a children
list. All we have to do is replace these two lists by dictionaries whose
keys are attributes and whose values are the parents or children lists for
those attributes. Finally, we add Python properties shield the dictionary
lookup from the rest of Leo. We are talking about maybe 50 lines of code!
As far as the rest of Leo is concerned, vnodes *still* have parents and
children lists. The switcheroo happens totally invisibly, when the user
wants to see another view. The attribute changes and that changes what the
vnode dictionary/properties "deliver" to the rest of Leo.
To recap: What we see depends only on the attribute that defines the
view. This attribute determines what parents and children lists become
active. So easy. So very powerful.
Each *current view* will show only the nodes with the given attribute.
To repeat, attributes can be composed of other attributes, so in effect
each view can be associated with an *arbitrary set* of attributes. This
is an *astoundingly* general data structure.
The real challenge lies in assigning different colored links to nodes.
I'm still trying to wrap my thoughts around all of this.
As always with truly huge Ahas, it's already impossible to know exactly
what thoughts lead to it. As soon as the Aha happened, the world changed
so much that the past becomes hard to reconstruct. But for sure the
1. Most importantly, the consensus has been building among the usual
suspects that attributes are a more intuitive, and perhaps more powerful,
alternative to clones.
2. For the last year I have been trying to ignore the fact that sometimes
clones get in the way. This was the meaning of today's remark that "I love
clones, I hate clones".
3. John's remark about attributes and hoists certainly triggered the
avalanche.
*Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes
complexity. In particular, both hoists and chapters are a (mildly
successful) attempt to make clones do the work of attribute-based views. In
the new scheme, we simply re-thread nodes that we want to be part of the
new view.
*And notice*: when we require that views be made of clones we can *not*
change any parent/child relationships. But that constraint completely
disappears when we use attributes to define views.
*Summary*
This is one of the most momentous Aha's in Leo's history. It was
completely unexpected this morning. It is almost too easy to make it
happen. I may do it this evening.
There remain important user interface questions concerning how nodes get
assigned various colored threads, but I have faith that the result will be
truly amazing.
1. Searches can be limited to a single view (thread color). If we don't
use clones in a view, each search will find a node at most once. This will
erase my biggest pet peeve about Leo!
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
3. It will be *very easy* for attribute editors to show nodes having
those attributes in the most natural way *for that attribute* without
being constrained in any way by other organizations of the data. Yes, this
is really just a restatement of 2, but it's different in practice.
No way would this Aha have happened without the interesting conversations
that have taken place in the last few months. Well done, all of us!
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Richard Andersen
2016-06-15 17:00:05 UTC
Permalink
Thank you for posting your UI design, Conor.

Really nice!
Post by john lunzer
That is pretty rad, thanks for sharing!
Post by Conor White-Sullivan
This is amazing to come across.
I discovered Leo today after scouring the web trying to find some UI
where people were merging trees to create this a multi-dimensional dag, as
you describe. Totally in love with what you're doing.
I also had the realization recently that layering trees to form a graph
could be incredibly powerful
Here's the UI I built this weekend to get started
<https://lh3.googleusercontent.com/-T_L5LZZPBhM/V06JBKAtnQI/AAAAAAAAAb0/OdRt_KcVOTonmv6KDlL2eki87A6KKwp-QCLcB/s1600/treedom2.gif>
Now just have to figure out a Clojure workflow and I'll be using your DAG
editor to build my graph editor ;)
Post by Edward K. Ream
John Lunzer's recent remarks has triggered one of the biggest Aha's in
Leo's history, one that was totally unexpected until this afternoon.
Leo's fundamental data structure is a tree of nodes. More accurately,
it is a Directed Acyclic Graph or dag. Links in such a graph can point
"down" the tree, but never up, so there are no cycles. Leo's clones are
well defined just exactly because there are no cycles. Given a node, we
know precisely *and* intuitively which nodes are descendants. Because
of clones, a node may have more than one parent.
Here's the Aha. Imagine this data structure as being linked with
*black* thread. Now imagine another *completely independent* set of
*red* threads. The only requirement is that the links defined by the
red threads must *also* be a tree/dag. That is, there is *absolutely no*
necessary relationship between the red and black threads.
Now imagine that every Leo attribute creates its *own* sets of
links/threads. *We have a new view for every attribute.* Let's call
such a data structure a *multi-threaded tree/dag*. Trees might actually
be enough, but I'm not sure so I'll refer to tree/dag (tree or dag).
*Important*: some nodes may not have any thread running them for some
colored threads (attributes). That's just fine.
Alas, the term "multi-threaded data structure" is commonly used for data
structures that can be accessed by independently running threads. That's
not at all what I am talking about.
I am not aware of anything like this in graph theory. Could this be a
truly new idea? I really have no idea.
Of course, you could call the resulting structure a general graph, and
technically it is, but how the data structure will be used inside Leo is *very
*different. Instead of a single, unintuitive mess, we have a collection
of easily traversed trees/dags. *We instantly have an arbitrary
dimensioned graph*! Each color creates a new dimension. Of course, we
only *see* one dimension at a time, but attributes may be the
*composition* of other attributes (unions, intersections or other
relations), so this is no real restriction.
And listen to this. *It is astoundingly easy to create this multi-dag
in Leo*. At present, each vnode has a parents list and a children
list. All we have to do is replace these two lists by dictionaries whose
keys are attributes and whose values are the parents or children lists for
those attributes. Finally, we add Python properties shield the dictionary
lookup from the rest of Leo. We are talking about maybe 50 lines of code!
As far as the rest of Leo is concerned, vnodes *still* have parents and
children lists. The switcheroo happens totally invisibly, when the user
wants to see another view. The attribute changes and that changes what the
vnode dictionary/properties "deliver" to the rest of Leo.
To recap: What we see depends only on the attribute that defines the
view. This attribute determines what parents and children lists become
active. So easy. So very powerful.
Each *current view* will show only the nodes with the given attribute.
To repeat, attributes can be composed of other attributes, so in effect
each view can be associated with an *arbitrary set* of attributes.
This is an *astoundingly* general data structure.
The real challenge lies in assigning different colored links to nodes.
I'm still trying to wrap my thoughts around all of this.
As always with truly huge Ahas, it's already impossible to know exactly
what thoughts lead to it. As soon as the Aha happened, the world changed
so much that the past becomes hard to reconstruct. But for sure the
1. Most importantly, the consensus has been building among the usual
suspects that attributes are a more intuitive, and perhaps more powerful,
alternative to clones.
2. For the last year I have been trying to ignore the fact that
sometimes clones get in the way. This was the meaning of today's remark
that "I love clones, I hate clones".
3. John's remark about attributes and hoists certainly triggered the
avalanche.
*Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes
complexity. In particular, both hoists and chapters are a (mildly
successful) attempt to make clones do the work of attribute-based views. In
the new scheme, we simply re-thread nodes that we want to be part of the
new view.
*And notice*: when we require that views be made of clones we can *not*
change any parent/child relationships. But that constraint completely
disappears when we use attributes to define views.
*Summary*
This is one of the most momentous Aha's in Leo's history. It was
completely unexpected this morning. It is almost too easy to make it
happen. I may do it this evening.
There remain important user interface questions concerning how nodes get
assigned various colored threads, but I have faith that the result will be
truly amazing.
1. Searches can be limited to a single view (thread color). If we don't
use clones in a view, each search will find a node at most once. This will
erase my biggest pet peeve about Leo!
2. Every view (attribute) can define/create its own set of parent/child
relationships, independently of all other views. Afaik, no other data
structure is this flexible while still remaining intuitive.
3. It will be *very easy* for attribute editors to show nodes having
those attributes in the most natural way *for that attribute* without
being constrained in any way by other organizations of the data. Yes, this
is really just a restatement of 2, but it's different in practice.
No way would this Aha have happened without the interesting
conversations that have taken place in the last few months. Well done, all
of us!
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
rengel
2016-06-18 05:36:09 UTC
Permalink
This discussion reminds me of some other attempt, to create a 'universal
data structure': Ted Nelson's ZigZag:

http://xanadu.com/zigzag/

https://en.wikipedia.org/wiki/ZigZag_(software)

Trying to link everything with everything else in every conceivably
possible way.
May be there are some usable ideas in it.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Edward K. Ream
2016-06-21 13:04:33 UTC
Permalink
Post by rengel
This discussion reminds me of some other attempt, to create a 'universal
​Thanks for these links.

Yes, I thought my Aha was important, but at present I don't see much use
for multi-colored threads. ​They look like a solution in search of a
problem. Otoh, the "perfect problem" might exist :-)

Instead, I keep coming back to how important the clone-find commands are.
They solve all the problems that I actually have. Still, there may be
other problems for which the clone-find commands aren't the solution...

So we can ask, what problems might be suited to multi-threaded trees, or to
zzstructures? Multi-thread trees aren't exactly general graphs, which are,
in fact, the most *general* data structure. But generality does not equal
power. Instead, the additional structure provided by multi-thread trees is
not a limitation, but instead a source of additional power.

​In short, I suspect there are good reasons why neither zzstructures nor
multi-threaded trees suggest great new applications. If you know of any,
please let me know.

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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
derwisch
2016-07-06 09:10:35 UTC
Permalink
Post by Edward K. Ream
Yes, I thought my Aha was important, but at present I don't see much use
for multi-colored threads. ​They look like a solution in search of a
problem. Otoh, the "perfect problem" might exist :-)
Hm. I remember trying to import a data structure into Leo, and using Leo as
an editor of this structure. This broke during the transition of Leo into
Qt (I think) which brought with it (if I'm not mistaken) the unification of
vnodes and tnodes. I am not willing to wrap my head around this interesting
approach of multi-dags, and if it had helped me back then (my bickering
about the transition back then pre-dates the switch of this forum to Google
Groups), just wanted to leave a general remark that sometimes this extra
flexibility is exactly what you need.
--
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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Edward K. Ream
2016-07-06 13:45:19 UTC
Permalink
On Wed, Jul 6, 2016 at 4:10 AM, derwisch <
Post by derwisch
Post by Edward K. Ream
Yes, I thought my Aha was important, but at present I don't see much use
for multi-colored threads. ​They look like a solution in search of a
problem. Otoh, the "perfect problem" might exist :-)
Hm. I remember trying to import a data structure into Leo, and using Leo
as an editor of this structure. This broke during the transition of Leo
into Qt (I think) which brought with it (if I'm not mistaken) the
unification of vnodes and tnodes. I am not willing to wrap my head around
this interesting approach of multi-dags, and if it had helped me back then
(my bickering about the transition back then pre-dates the switch of this
forum to Google Groups), just wanted to leave a general remark that
sometimes this extra flexibility is exactly what you need.
​Yes, there is always the possibility that multi-threads will be needed in
some application. Until then, the extra generality has costs Leo's normal
users should not have to pay.

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 leo-editor+***@googlegroups.com.
To post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Loading...