On Mon, Sep 23, 2013 at 2:45 PM, Terry Brown terry_n_br...@yahoo.comwrote:
On Mon, 23 Sep 2013 13:17:04 -0500
Edward K. Ream edream...@gmail.com wrote:
2. what does p.self_and_subtree() return?
Ideally, same as it would anywhere else, if it were possible to
construct a sufficiently
On 9/23/2013 3:45 PM, Terry Brown wrote:
hysterical raisins
Perfect. *slow clap*
That just made my day :)
--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
I've run in to this many times, the 'insertBefore' example was just the
most recent.
It seems to me that the API for handling top-level nodes is
inconveniently inconsistent with the API for handling non-top-level
nodes. Here's my (corrected) insertBefore() snippet:
nd = p.insertAfter()
On Mon, 23 Sep 2013 10:18:36 -0400
Jacob Peck gatesph...@gmail.com wrote:
I'm going to +1 this request -- I've run into issues with needing the
parent of a top-level node myself.
Another implementation detail would be what do you get when you ask for
c.virtualRootPosition()'s parent? I
On Mon, Sep 23, 2013 at 9:15 AM, Terry Brown terry_n_br...@yahoo.comwrote:
I've run in to this many times, the 'insertBefore' example was just the
most recent.
Your complaint is understandable, but I am not likely to consider a fix
now, with 4.11b1 so near.
It seems to me that the API for
On Mon, 23 Sep 2013 07:47:24 -0700 (PDT)
Fidel N fidelpe...@gmail.com wrote:
What should happen then with iterators that get the list of parents?
Should c.p.parents() include that node?
I don't think so, Leo's data model is firmly established as a list of
top level nodes with no parent, so any
What should happen then with iterators that get the list of parents?
Should c.p.parents() include that node?
I like the idea very much btw.
On Monday, September 23, 2013 4:15:24 PM UTC+2, Terry wrote:
I've run in to this many times, the 'insertBefore' example was just the
most recent.
It
On Mon, Sep 23, 2013 at 10:30 AM, Terry Brown terry_n_br...@yahoo.comwrote:
In particular, the call to p.moveToRoot handles a lot of details
not likely to be handled by a virtual root position.
There's the nub, can a specially constructed position work this way?
I'm not familiar enough with
On Mon, Sep 23, 2013 at 9:18 AM, Jacob Peck gatesph...@gmail.com wrote:
Another implementation detail would be what do you get when you ask for
c.virtualRootPosition()'s parent? I suggest that it just returns itself,
so that we don't need icky guards in scripts.
A very bad idea.
Icky
On Mon, Sep 23, 2013 at 10:30 AM, Terry Brown terry_n_br...@yahoo.comwrote:
I'm not proposing changing anything that exists, including existing
behaviors.
I'm glad we are having this conversation, for several reasons. First, rev
6032 adds p.insertBefore, and uses p.insertBefore to simplify
On Mon, 23 Sep 2013 13:17:04 -0500
Edward K. Ream edream...@gmail.com wrote:
Second, c.virtualRootPosition is a bad idea. The intention was to avoid
special cases, but the proposal creates its own special cases. Given:
p = c.virtualRootPosition():
1. what is p.h? p.b?
On Mon, 23 Sep 2013 14:45:39 -0500
Terry Brown terry_n_br...@yahoo.com wrote:
So, I don't think c.proxyRootNode() would create any problems, *if* it
was possible to implement in a way that created a position that wasn't
a landmine, but I think the hide-the-details methods .insertBefore()
and
12 matches
Mail list logo
