On Wed, Oct 5, 2011 at 12:32 PM, Terry Brown <[email protected]> wrote:
> Plugins--> Qt only plugins-->@file contextmenu.py-->deletenodes_rclick
>
> also addresses this issue, it converts the list of selected positions
> to a list of vnodes, and then tries to delete them using
> c.vnode2allPositions(v) and c.positionExists(pos) to see if they haven't
> already been deleted. But I suspect that's potentially expensive (calling
> c.vnode2allPositions(v) all the time) vs. Michael's approach.
I agree. Michaels's approach appears to be much better.
BTW, on today's bicycle ride I considered the following:
p = c.rootPosition()
while p:
if p.isMarked():
next = p.nodeAfterTree()
p.doDelete()
p = next
else:
p.moveToThreadNext()
This *almost* works. That is, it works unless p.nodeAfterTree() ==
p.next(). In that case, the code will fail, because, in effect,
p.next() changes. However, there is a cute hack:
after = p.nodeAfterTree()
next = p.copy() if after == p.next() else after
p.doDelete()
p = next
That is, if p has a next sibling (after == p.next()) the next position
(after the move) will be equal to p (before the move)! Otherwise,
p.nodeAfterTree will, of course, remain unchanged.
This is the *fastest* thing that could possible work :-) Indeed,
computing p.nodeAfterTree() is usually extremely fast. Maybe this
hack is just a bit too clever. The reverse traversal is more natural.
But I'm tempted...
Anyway, the point of all the new work, and Michael's big contribution,
is to focus on what *doesn't* change, be it a position or a vnode.
> In the end it would be nice to have
>
> apply_to_vnodes(function, vnode_list)
>
> with perhaps a wrapper, apply_to_positions(function, position_list)
Yes. The focus on vnodes as both a proof device and an implementation
strategy suddenly has appeal.
Having said that, your idea seems a bit too general to be doable.
Undo is going to be a big problem.
Big sigh. Once again, Bernhard Mulder was ahead of his time. He
proposed an *general* undo strategy based on vnodes. My brother Speed
likewise.
I am tempted to revisit all the old undo code with this in mind, but
I'll resist :-) However, the move/delete-marked commands *do* require
new undo code. I'll use them as a prototype for a vnode-centric
approach.
> although it might not be possibly to combine behavior appropriate to
> both copy/paste type ops. and delete in the same interface.
Move, paste, clone and delete are all subtly different. It's probably
best to accept those differences.
> Another probably less critical question is how to handle pasting of
> non-contiguous and / or multi-level sets of selected nodes. But just
> being able to paste a contiguous set would be a big plus.
I'm not sure I understand. Pasting a "contiguous set" in the same
place should be straightforward. Pasting in multiple locations,
however, would be difficult.
> And... although it makes sense to be able to do all these things based
> on Marked status, I think it should also be possible to do them based
> on multiple selected nodes in the tree - being able to manage these
> nodes as easily as people have come to expect from interfaces like
> GoogleEarth's places tree and various browser's bookmarks trees is
> important for data management applications in Leo. Perhaps less
> important for coding applications, but that's not all that Leo does ;-)
Internally, Leo can used the "visited" bit as a substitute for the
marked bit. This bit exists precisely for the temporary use of
commands. It is never archived. Thus, the data part of the
algorithms should carry forward unchanged.
Edward
--
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.
