active_path issues + clone-wars solution idea

[HansBKK]

This is IMO a fantastic extension of Leo's functionality, thanks Terry!

See attached screenclip for simple test case


--------------------
First, generic @ <file> clone-wars wishlist item - based, perhaps naively on my @nosent solution

   - let me clone the @shadow node directly rather than having to use the "single-child + @all" workaround employed here
     - by letting me put an @directive in the body of the top-level "!masterByCreationDate" that means
     - "don't do any file IO from here down"

I imagine if it were that easy it'd already work that way, but hey worth tossing out there just in case. . .


====================
AP-specific issues:

If I initiate "Set node to absolute path" directly on the file node, AP changes theheader to @shadow E:\aasync\Libraries\hh-lib-documents\quotes\serenity\Desiderata.txt - not pretty, but explicit, transparent.

However if I "Set node to absolute path recursive" on an ancestor node, all the @ <file> node headers remain the same; the actual change "under the covers" is a @path statement insertion in the sentinels - and in the case of @shadow this is "nicely hidden away" in the xDesiderata.txt. However once my org-tree refactoring or temporary working with clones has ended, it's pretty difficult to now reverse this (back to relative path'ing) without programming, especially if the tree contains thousands of files (in my case sometimes tens of thousands).

If I've missed something, please let me know. Otherwise, some off-the-cuff 2¢ suggestions, in my perceived order of importance:

  - Make the location of the full-path string consistent between the once-off and the recursive commands.
  - Add "reversing" commands, e.g. "Set node to relative path (recursive)"
  - Allow the user to set whether it's going to be ugly/transparent or nicely hidden.
  - If using the hidden @Path statement (which I prefer), can you think of some sort of visible indicator of the fact that it's now absolute?
    - I guess this is becomes a core issue, as all I can think of is another icon flag like the red-arrow for cloning
    - maybe a pin (tack) symbol for absolute?
 
Perhaps if the relative commands were implemented, then the "hiddenness" of the absolute status isn't that important since it is now so easy to reverse?

Obviously just thinking at the keyboard, I'm sure (if this is indeed a real problem) you'll come up with a more elegant solution than I can think of.


--------------------
(side question, still AP-specific)

I take it the @path **must** be in the header of the top-level folder (ITC "Libraries")? active_path doesn't activate if **all** of them are "prettily" buried in the body. If so NBD, just checking

[Terry Brown]

On Sun, 25 Dec 2011 23:02:29 -0800 (PST)
HansBKK <han...@gmail.com> wrote:

> See attached screenclip for simple test case

Can't really keep up with all the ideas you're generating :) but it
seems you wouldn't want clones in your master tree because editing them
elsewhere will change the 'master' copy?

Cheers -Terry

[HansBKK]

On Monday, December 26, 2011 11:54:38 PM UTC+7, Terry wrote:

On Sun, 25 Dec 2011 23:02:29 -0800 (PST)
HansBKK <han...@gmail.com> 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.

[Terry Brown]

On Mon, 26 Dec 2011 19:27:58 -0800 (PST)
HansBKK <han...@gmail.com> wrote:

> 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-)

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.

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?

Anyway, I've made a note to look at the inconsistency and
configurability issues you noted.

> The "master"
> tree structure carries no meaning, its only purpose is to have an
> unchanging location to link UNLs to

Ok, that makes sense :)

Cheers -Terry

[HansBKK]

On Tuesday, December 27, 2011 10:29:15 PM UTC+7, Terry wrote:

On Mon, 26 Dec 2011 19:27:58 -0800 (PST)
HansBKK <han...@gmail.com> 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 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.