Is it possible to do proper outlining?

[schferk]

For those UR users having checked that link already, please note in the meanwhile I buried their "network" version, too (with a special mention of UltraRecall there - I know whom to treat well).

[schferk]

Just a short rectification of my stance that proper outlining is outlining, whilst "inlining", i.e. additional outlining within specific items, is to be avoided at all cost.

As I explained in the meanwhile in the outliner forum, I'm not so sure of this - perhaps false - dichotomy anymore,

and whilst I'm strictly against dedicated one-pane outliners, because of their inability to store your working material (it's no coincidence that the one rather successful "one-pane" outliner, Bonsai, really is a hybrid outliner that in fact does offer a special - but badly realized - "content" field for every item),

I now prone EDIT: defend (prôner is French), again, what I had even realized in my own IMS, 15 years ago, a double function that does not offer "real", multi-level outlining within items, but which offers conversion of ONE-level "outlining" within items

(= by (at wish, even automatically numbered) headings or just bold-formatted single lines after blank lines and above other lines not separated by a blank line (= "smart collection of what is to become a separate item")

( EDIT 3 : To give a precise description: As a "heading", the sw would identify any text line that is first in the text field or beneath a blank line, and that is followed by a LONGER line, but with the exception of several lines beginning with a "-" or something like that; such lines would be counted as "text"; as "text" would be identified any lines, including blank lines (= several paragraphs in a row), up to the next "heading", or up to the EOF. The bold formatting would be automatted for IMPORTING such headings plus text into a text body, from separate items (= downwards), but it wouldn't play a role in identifying the headings for EXPORTING into tree items (= upwards). It goes without saying that this system is intended to automate this upwards shuffling, WITHOUT relying on any pre-figured "paragraph formats" or such since these are absent from most editors used in outliners and such - so it's rather "primitive", not MS Word "class", but it works very well. It also goes without saying that any IMS that indeed uses "paragraph formats" (which is not the case currently for UR), would rely upon (upwards), and provide (downwards) "header" formats, instead of just boldfacing those lines (downwards). Another clarification: Those "headings" are identified mainly because they are immediately (!) followed by a longer line, whilst several paragraphs following each other, except for the above-mentioned exception of lists, are separated by blank lines: so, a rather short paragraph within a sequence of paragraphs (under the same heading) will NOT disturb this identification scheme, that would only fail in rare cases with a heading and then a first paragraph even shorter than the heading. So, in the end, you could even discard the "followed by a longer line" part, just identify by preceding blank lines, vs. two "paragraphs" immediately following each other: Then, the first one is a heading if it's preceded by a blank line or is the very first paragraph in the editor field. And lists would be identified by its lines (= 2 or more consecutive paragraphs without blank lines between them) beginning with the same special char, whatever that special char might be. Simple. )

into separate "siblings" = common children of the current item, and vice versa, meaning a function that shuffles any children of a given item as text paragraphs into that item, the former items' titles becoming bold (and, at wish, numbered) headings above such text paragraphs.

I do NOT think that real outlining within items might be of use, but indeed, translation of sub-items into (single or multiple) paragraphs of their former parent item should be possible, as well as translation of paragraphs text amounts within an item, into separate items whenever you'll realize that these become too much "developed" as to logically remaining within such a single item becoming convoluted, and of course, this double transition, both ways, should be automatted, as described above.

As for further outlining, I think that anytime you'll realize that you'd "need" even second-level outlining within your item, you'd simply transfer your first-level outlining there into such separate child items, and your further headings within these siblings will become your "second-level" outlining there, and so on ad libitum, i.e. any further outlining except for just one level within given items should be realized by further indentation within the tree, but in order to have a plastic system, without the need of much manual fuss whenever you realize your separate items are too short and / or too similar in order to remain separate items, or that your text becomes too voluminous in order to stay together within one item, transition both ways should be facilitated by automatic processing by your IMS - and since I programmed it myself at that time, let me assure you that from a technical pov, nothing could be more easy to implement in a sw like UR, both ways.

EDIT 2 : It just occured to me that such a "bottom-up writing" might be ideal for people who prefer UR and such for "stuff storage", but who've been clinging to other means (one-page outliner, text processors like MS Word, etc.) for redaction work, for "writing":

In fact, write within the one-level "outlining space" of any item, develop thoughts there, take advantage of your "flow" there, not bothering with separation into different items. Then, run the "distribute into siblings" command - takes a sec or so -, and continue to develop sub-thoughts in any such sibling, again to the point of "needing" distribution into different siblings, and so on: This doesn't hinder you at all to create additional such siblings, uncles, nephews, whomever, being left empty at the given moment, and in order for them to contain data later.

This way, you'll have got the best of both worlds, 1-pane and 2-pane at the same time, and there'll be no need whatsoever anymore to split up your writing into two different applics, with all those problems such a setting brings with itself, meaning the import from your "writing" applic into your "storage" applic will perhaps be flawless, but what about exported parts that need "revisiting", is re-import into your 1-pane outliner really easy? Which means you'll invariable end up, in such settings, with writing concurrently in both applics, creating total chaos in the overlapping and clashing of these different (multiple) parts.

All these problems are perfectly avoidable by the described original writing within your UR items, together with isolating any "rather devoped part" into separate items, and doing any interactive editing within these different UR items, providing perfect plasticity in both directions whenever needed, from connected text to tree and back to text body.