[Spliff]

My explanation above probably was sub-optimal.

Currently, "FROM tree TO content" functions as follows:
From the Help: "Combine Info Items":
"1. Select the Info Items to be combined
2. Copy them to the clipboard (Edit | Copy or Ctrl+C)
3. Navigate to the location for the new combined Info Item
4. Use the Paste Rich Text/Paste Rich Text with titles option to paste the combined Rich Text (available at Edit | Paste Special on the menu)"

In fact:

- I select the items (after having them first put into the right tree order, in order to get the combined text in the order I want it to be then)

- I ^c them (in the tree)

- I go to the target item*

- I trigger "Edit - Paste Special - Paste Rich Text with Titles"**

- UR then creates a new child item beneath the target item; this new item gets as
title, the title of the first one of the items-to-be-combined, and its content gathers the richtexts from the items-to-be-combined, in order, each of them preceded by the respective original item title

- And since that was ^c, not ^x, the original items-to-be-combined stay where they are (see Help text); beyond the Help text, the same procedure also works with ^x, with the original items then, as to be expected, put into UR's bin, so the user can choose among both (In other words: even with ^x instead, the "Paste Rich Text with Titles" is NOT greyed-out but works as expected.)


* = "Target item": As said above, I don't really want that additional item (=child item of the target item) in most cases, but just those gathered titles plus contents being appended to the content of the target...

** = "Paste Rich Text with Titles": As before, the target item has focus, but when not in tree but in content, this "Paste Rich Text with Titles" is greyed-out, albeit all the necessary data is already in the clipboard, and practically all of the necessary processing algorithm is already within the code:

It would just suffice to put the very same data which otherwise (i.e. if the target item's focus was in tree, not in content) UR would then paste into the (unwanted) new item's content, into the current content (which has focus, and at the cursor position, like any other, "regular" ^v would do) - by NOT greying out the command anymore.

Thus, at the end of the day, I just would like the very same code to be applied, just leaving out the intermediate creation of the new child item:

- with that, as currently, if target item's focus is in tree, and

- without that (the command not greyed-out anymore), if target item's focus is in content

And then, most uses of the command, not only mine, would be triggered from target's Content, promised! ;-)


EDIT:

I forgot to mention: The main and general (!) use of that command would not be the consolidation of several items' contents, but just the smooth shifting of title AND content of one item, into the content of another one, i.e. the dissolution of one item (of which the content then hasn't grown into the size or importance mistakenly foreseen at its creation), into another one (which takes it in as just an additional aspect) - and for which the creation of an intermediate item, just to get both title and content of the item into clipboard, and into target's content, instead of just either of them (i.e. ^a, then ^c in content (which leaves the title out), vs. ^c in tree, then Paste special - Paste text in target's content (which leaves out the content)), in every action, is out of the question.

Thus, for smooth editing, the suggested function would make significantly sense.

(And that's why an ideal solution would have been to make an additional command which, from the tree (!), i.e. from the tree entry of the target item, would just append a blankline, title(s) and content(s) from clipboard into the target's content field, without the user having to focus the content field, and then manually navigate to the content's end (^{end}), for then triggering the above-mentioned (but in content not greyed-out anymore) command "Paste Rich Text with Titles" - if this "workflow" could be consolidated in just one, additional command, to be triggered, as said, from the target's tree entry, this would be of real beauty... but then, even the "minimal" solution, sketched above, would be more than welcome indeed.)