On Tuesday, December 27, 2011 10:29:15 PM UTC+7, Terry wrote: > > On Mon, 26 Dec 2011 19:27:58 -0800 (PST) > HansBKK <[email protected]> wrote: > > I suspect "Set node to absolute path recursive" came in to being > because I was making recursive versions of all the commands - to be > honest I don't see why you'd want to do it. > > It certainly seemed more useful back when I was under the impression that I could sensibly clone @ <file> nodes 8-)
Hence my munging these two seemingly unrelated issues in one thread. However it's made me realize that if someone did clone their @<file> nodes, the "reversal" code would need to use the current tree position to determine which relative path was "home" wouldn't it? And the "other" location would no longer be mirroring the filesystem tree, which would be fine, but only if that was what the user intended. definitely a can of worms. A single "Set node to absolute path" is obviously useful for breaking off a > part of the tree and moving it. Perhaps you're using the recursive version > to prep the whole tree for easy dismantling? > I'm currently planning to use active_path for mirroring the filesystem tree with relative paths, and "sectioning" out any chunks I want to clone elsewhere (the "workaround" illustrated with the poem content in my screengrab). Unless of course the ""@noIO" functionality become possible down the road. So if you were to decide to remove the recursive version due to lack of a significant use case that would make sense to me. If you're going to keep it, and not implement a "recursive reversal" then I would suggest using the heading string rather than the sentinel, at least by default. That way the user would have to explicitly turn on the "bury in sentinel" as well as the "use @shadows" and then they've created their own usability problem, rather than active_path's default. > The "master" tree structure carries no meaning, its only purpose is to > have an unchanging location to link UNLs to > > Ok, that makes sense :) > I'm starting to think not 8-) Maybe to just use it for those nodes that I think I'll actually want to link to. Doing it globally is starting to look like a YAGNI <http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it>feature of my SOP (I think Ville was the wise man pointed this fine principle out to me) Anyway thanks for the acknowledgement, and more importantly for the plugin, IMO it enables functionality for Leo that would justify the learning curve for that one aspect (filesystem meta-manager) alone. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/w4OzmLNMQqAJ. 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.
