View Single Post
  #6  
Old 04-30-2021, 05:42 AM
Spliff Spliff is offline
Registered User
 
Join Date: 04-07-2021
Posts: 192
Some add-ons (details; I can't edit the above anymore):

ad p) (sudden selection of the whole tree after moving subtree; also when "indenting" subtree)

This also and often (here, "often" is correct) occurs by "indenting" a subtree, i.e. given (again) a sibling to become the new parent of a subtree, but instead of cutting the subtree, then paste it into the new parent (^x, ^v), I move the subtree (by multiples "move up") right beneath its new parent-to-be, then do a "move right" (which will expand the parent item, as expected here, but will also, and often, then select the whole tree).


ad e) (items from an "outdented" block "left behind")

One example here that may be helpful in HOW this occurs (and it occurs almost every time, for blocks of beyond just 3, 4, 5 items):

Inbox (= first level) with about 120 items; item on position around-20 had 11 direct children, which are to be "outdented" / "upgraded" = to be made siblings of the siblings of their parent item = are to be on second instead of third level. Thus, below that indented block, there are some 80 other items on the target level of the block in question. I select the block (as said, 11 items) and do "move left". Result beneath the former parent item (all 11 items are its siblings now, but not, as would have been expected, directly beneath it):

4 others, sib1, 4 others, sib2, 4 others, sib3, 2 others, sib4, 2 others, sib5, 1 other, sib6, 1 other, sib7, 1 other, sib8, 1 other, sib9, 1 other, sib10, 1 other, sib11, and then the rest of the others.

(As said, with about 8GB of free work memory, an i7 processor and with a good (and the data traditionally storing, not the newer, lesser kind) WD "Red" HDD.)

See also below for allegedly the same "leaving behind" problem for which something like a "packet manager" would be needed even if that meant that the command, henceforward, would take more time to complete (correctly, then).


ad n) ("move first/last")

When I said there, "This way, this command does not help with this problem, and also, I would not expect these two commands [i.e. "Move first" and "Move last"] [to be] in the Tree menu, but in the Item menu, since as said, they don't work but on single items.", I didn't want to make the suggestion to move them into the "item menu", but it would be great if they could be enhanced in the way that they, too (as "move left/right and up/down) could process blocks / selections of more than one sibling, and, as said before, the same "packet manager" as in e) would obviously be needed then in order to prevent siblings from being "left behind".


All this being said, I'm very thankful for your kind and hyper-fast resolving the "formatting flags" problem, and adding these further details to the tree problems and suggestions should in no way being considered as my trying to rush things; I would have used the "Edit" function instead if such edits were possible even after some days.


x) EDIT: One more: On the other hand, when I expand the very last item visible on screen (or then some item very near that very last "visible" position), the tree systematically stays there, even after expanding, i.e. in order to see any "freshly expanded" item, I have to scroll (PGDN; this PGDN then will put the very first one of the expanded child item as first visible-on-screen item though, which for very long lists of expanded children is what you'd expect; this PGDN should just not be necessary in this situation).

Last edited by Spliff; 04-30-2021 at 10:27 AM.
Reply With Quote