Hoist / New Tab: possible in combination?

[Spliff]

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