On Monday, December 26, 2011 11:54:38 PM UTC+7, Terry wrote: > > On Sun, 25 Dec 2011 23:02:29 -0800 (PST) > HansBKK <[email protected]> wrote: > > > See attached screenclip for simple test case > > Can't really keep up with all the ideas you're generating :) > Yes sorry about that, I'm trying to keep the firehose under control I really am, and I appreciate your responding.
> but it seems you wouldn't want clones in your master tree because editing > them elsewhere will change the 'master' copy? > Actually that part of my post is by the by, probably of little value given my current low level of understanding and your feelings about cloning 8-) I moved that topic to the end, feel free to ignore unless it seems an idea worth pursuing for the sake of Leo's future evolution. -------------------- What about the "Set node to absolute path recursive" issue I outlined? To my mind, if you enable batch conversion to absolute @paths, there should be either an automated way back to relative ones (preferred), or at least a visual indicator of which ones need to be fixed manually out in the filesystem. Right now I'm using external regex search-and-replace tools to find the abspaths hidden in the shadow files, which is fine but definitely a kludge 8-) Or I'd be very happy to find out I missed something about how active_path and core @path are intended to work? ==================== > but it seems you wouldn't want clones in your master tree because editing > them elsewhere will change the 'master' copy? > In this scheme **every** node containing content is necessarily a clone, it's "baked in" to my "Ctrl-N" create a new node workflow. The "master" tree structure carries no meaning, its only purpose is to have an unchanging location to link UNLs to, that way I only have to deal with updating inbound links as a result of heading strings changing, not from refactoring the "real" (meaningful) outlines. I see @ <file> nodes as a type of org node/view nodes, they just act as "content free" functional organization structures, import/export generators, and using active_path with relative @paths made me realize they can't be cloned the way Leo works ATM. Hence my idea of a "@noIO" directive available meaning "ignore any descendants in this tree from the point of view of @ <file> functionality" - or some other mechanism to ensure they only input/output in one location would allow for safe cloning of @ <file> nodes directly. -- 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/-/6xfNPIxIaeIJ. 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.
