Currently, when one clones an expanded node, the cloned node is shown
as unexpanded; thus expanded/unexpanded is an attribute that may be
distinct between clones. There are likely others, though I'm not
aware that I use them (perhaps an internal optimization that tracks
parents?); I think I remember that the cleo plugin also kept data that
might differ between otherwise identical clones.
It would be fine with me if cloning a node had the side effect of
setting it unexpanded; setting it to expanded would almost always be
too visually cluttered. I assume it would have no effect on the
expanded/unexpanded attribute of child nodes.
I could easily be wrong about cleo, which I toyed with but haven't
used seriously. If anyone reading this has a plugin that cares about
this, I advise you join the conversation now :-).
- Stephen
On Jul 6, 1:14 pm, "Edward K. Ream" <[email protected]> wrote:
> On Jul 6, 11:56 am, "Edward K. Ream" <[email protected]> wrote:
>
> > It is looking like very few changes will be needed to make the one-
> > node scheme work:
> > In particular, the all-important p.moveToX methods should remain
> > unchanged.
>
> A subtle point has just now become clear to me: the p.moveToX methods
> (the foundation of all Leo's iterators) would have to be revised
> extensively to work in the graph world. But as I have said before,
> Leo's core is probably never going to support the general graph world,
> so there is no need to try to "reinterpret" what, say, threadNext
> means in the graph world.
>
> With this caveat in place, the work to be done should be
> straightforward.
>
> Edward
>
> P.S. The "reinterpretation" of p.moveToThreadNext for the general
> graph world would be non-trivial. For example, every test of the
> threadNext code would have to be "expanded" to test whether a link has
> already been followed. Equivalently, methods like p.hasNext() would
> have to test whether p.next() has already been visited (in a
> particular generation). The new code would be tricky to get exactly
> right, so it's good there is no need for it.
>
> EKR
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
