Continuing thoughts on an editor for trees: one operation we really want is to save a location (or many locations) and be able to return to it, for example Emacs's save-excursion or push-mark. The zipper data structure cannot handle multiple cursors in a tree.
Things become hairy if edits delete the saved point. I think the right thing is to go to the nearest ancestor which still exists.
If you cut a subtree with a saved point and immediately paste it elsewhere, the saved point ought to move to the new pasted location. If you paste something twice, it's less clear what do: maybe only the first paste counts. Maybe the cut and paste paradigm is broken. What about save-point-to-register, cut, jump-to-register (jumps to parent of cut subtree), paste, jump-to-register again (now jumps back into the restored cut subtree, or back to the parent where it last jumped)?
Another idea: nodes can have metadata attached to them, including generating a unique node identifier which can be searched for, perhaps quickly using an external index. The metadata also contain hooks into code, or policy, for what to do on the event of cut, copy, paste.
2 comments :
I wonder whether other cursors would simply be "bookmarks" into the tree? When you want to go back to one of the "other zippers", you simply find that bookmark (if it still exists).
(Ah, perhaps that's what you meant by your node metadata idea?)
I imagine that viewports onto the tree could be handled in the same way - i.e. the zipper would actually have to jump between bookmarks while updating the other viewport, if required.
Oleg has an article on zippers with multiple holes: http://okmij.org/ftp/Haskell/Zipper2.lhs
Post a Comment