[Spliff]

From Content to Tree: already perfect

- You select text content, then do ^c (copy) or ^x (cut)

- You navigate to the target item

- "Edit - Paste Special - Paste Text"
(This creates a new child item "beneath" the target item, with the content being your selection (as if you did ^v there), and with the first line/paragraph of your selection replicated as the item title, so that first line/paragraph is now existant two times: as item title, and as first paragraph of the text; it's debatable if this duplication is the very best solution in every situation, but then, we might then want to change the title, and then it's obviously wanted that the first paragraph has not been shifted to the tree, but replicated to it, so the current way seems best indeed)

- OR "Edit - Paste Special - One Item per Line"
(This creates multiple child items "beneath" the target item, one each for every line/paragraph in your selection, being titles respectively by that very line/paragraph, and with no content, logically; blanklines are skipped)

From Tree to Content: some wish for (easy) improvement

- You select 2 or more items, then you do ^c (copy) or ^x ("cut": in fact, after the paste, these "cut" items will be preserved, so you have then to delete them ({del}); considering that UR's functionality described here functions flawlessly, too, and that on the user side, there are TWO alternatives for choice, ^c OR ^x, I think that after ^x, the then "paste" command should indeed make disappear the selected items from their position, all the more so since in case of user "error", they will be available for retrieval within UR's bin)

- You navigate to the target item, go to content field (!)

- "Edit - Paste Special - Paste Text"
((^v instead would insert links (!) to the items instead))
(The other entries in that sub-menu are greyed-out here, with current focus in content field)
(This pastes the item-titles only into the content field, whilst any text of the items is lost (!) though, whilst it should be easy to split the command into "Paste Text - Titles only" and "Paste Text - with Content", since the necessary gathering algorithm is already implemented.)

The current solution for this is quite awkward, since you can consolidate the text bits, but within a new item only, and which will be created as a child item of your target item, whilst in many - I'm tempted to say: most? - use cases, you would want to just append your gathered text bits (together with their original item titles) into or to the already existant content of your target item itself, so in this - what I'd call the "regular" - workflow, you have then to manually select the whole content of the new item (^a, then ^c), then go to your target item, go to its content field, do the necessary ^v (or first, ^{end}, then ^v), go back to the unwanted, newly created, "intermediate" item, and delete that.

The current way of doing this might even be preserved, since it's already there, and some users might want it that way, but I'm sure most users would prefer to have it SIMPLE, additionally (!), as described above, so that when there is one item, or there are several items, copied (^c) or cut (^x), i.e. in the clipboard, AND the content field of some other item (i.e. the "target") has focus, the above-mentioned commands should be available from that sub-menu: "Paste Text - Titles only" and "Paste Text - with Content" (where, as indicated, Paste Text - Titles only" would correspond to the current entry "Paste Text")


Aside: It's interesting to see that freely moving elements from "content" to "inter-titling", EDIT: and vice versa, of course, and the alleged absence of this double functionality in 2-/3-pane "outliners" has always been the core argument of advocates for 1-pane "outliners" for the latter, and their core criticism against the former... whilst nowadays, there isn't a single, current one of the latter left (just some very old, (now) free, and with their development being stalled 10 or more years ago): Thus, the benefits of the former seem to outweigh those of the latter by far. ;-)

As described, the problem "from content to tree" has already been resolved perfectly by UR, it's just in the opposite direction in which currently UR's "workflow" isn't smooth enough, but as said, that problem could very easily be resolved! ;-)