Hoisting and Moving Items
I fully understand that the hoisting functionality is highly probably really complicated, so I don't know if doing something about this problem is possible, or if the coding work it demands, would make sense.
Priority should be that even with hoisting, no item / sub-tree should never be lost, and I can't say so from my observations so far, so I really admire this functionality, even as it is.
As above, given two tabs, the left one for the whole tree (database), with sub-trees A...Z, the right one hoisted to sub-tree S (for "Sub").
Now, working on the right (= hoisted) tab, I discover one or more items which don't belong in there; currently, selecting them (even a single one), cut it (^x), shift to the left tab (= full tree), navigating to sub-tree "T" (for "target", i.e. a position outside the (in the other, hoisted tab) hoisted part of the tree, doing ^v there will have NO effect, BUT when going back to the hoisted tab, the "cut out there" item thankfully is always there, it has not vanished.
Thus, for getting items / sub-tree out of hoisted parts of the tree, currently there are just two alternatives:
- gather them in some sub-tree "Export" within the hoisted tab sub-tree, then un-hoist that tab (> full-tree), then distribute those items to their respective, final destinations
- go to the tab representing the full-tree, navigate there to the item to be moved, do the necessary move over there... BUT this un-hoists the second tab, too! So there is no benefit in trying this, since any try to "get out" something out of a hoisted tree part will either be not successful or "un-hoist it all", so my first alternative seems to be the way to follow: gather those items, then un-hoist, then distribute within the full-tree, then hoist again
EDIT: "Copy" (^c, then ^v), on the other hand, works as expected, i.e. is successful on-spot, but then, what's going on "behind the scenes" for "Copy" is very different, obviously.
SECOND EDIT: Moving, in tab 1 (= full-tree) an item from outside the (in tab 2) hoisted part, INTO the hoisted part, will work AND then correctly appear also in tab 2 which (listening to the noise of my HDD), before being displayed again, obviously will be updated, i.e. UR checks the hoisted part of the full-tree for possible changes, then only displays the hoisted tab again.
Also, changes "WITHIN" (i.e. limited to) the hoisted part, be it in tab 1 or tab 2, are, when you switch to the other tab, correctly displayed over there, i.e. any change (be it in tab 1 (full) or 2 (hoisted)) will be processed in and for the full-tree (tab 1), and any switch (back) to tab 2 will "update" the hoisted part in there accordingly, whenever necessary.
So I believe to have better understood now how "hoisting" technically works - any processing is done upon the full-tree, with the hoisted part being updated whenever necessary? -, and this also seems to indicate that the moving problem described above should be resolvable quite easily? (I may be mistaken here though.)
Last edited by Spliff; 05-27-2021 at 05:33 AM.
|