Outliners vs. Inliners (and a little intro to programming with Outliners (but not Inliners, sorry, Steve!))

Posted by Fredy
Sep 1, 2012 at 08:51 PM

Stephen, in your thread “Submitted for your consideration” you expand on outliners = single-pane outliners vs. the other variety which should be given multi-worded names containing some “information” component anwhere and that nobody could ever remember of.

I’ve got bad news for you. Let’s see what outliners were originally. Pupils’, students’, researchers’ headings collections, WITHOUT any material = “content”, may it be pre-existing or only coming later. So, the “real” outline is our tree, within a 2-pane outliner.

I explained lots of things in the UR forum, just search for “proper outlining”, and you quickly will see a thread with about 1,800 views at this time; in the second part of it I explained my current IM system, but in the first part, I explained how your material should be distributed between tree and content pane - that’s highly instructive stuff if I may say so (if I hadn’t written one of the “best” (but unstable) outliners out there, I wouldn’t be as preposterous as that, but my findings come from years of intimacy by the inside, not just by oberservance and touching from the outside).

I tried the 1-pane variety, and I was subjected to the “lost in neighborspace” phenomenon, bad joke since there are hyperspace and neighborhood, but you see what I mean, even within a “closed hyperspace”, I was lost; outlines are exactly there to prevent this. And what should it contain, the outline? Any (even minor) sub-heading, in order to fulfill its guidance task. And that’s what I explained to the op there in the UR forum who had precisely asked for “proper outlining”, meaning inlining, for him. So I explained why he was mistaken, and gave all necessary details.

I am not criticising your need - and your enthousiasm with - the 1-pane variety, but your claim that it’s the pure one, is ostensibly erroneous, since your variety mixes up the outline and the material, which was never done within the original idea - on the contrary, you were asked to have your outline on one sheet of paper and doing your development on the other (where it was finally mixed up with the headings = replicated outline items, but as a result only, not for construction purposes), whilst “our” variety holds them apart, clearly presenting the outline that is NOT mixed-up with the content, except when we trigger the “export” function, where finally the outline and the development (or material) will be mixed up for presentation, publication, whatever = “the result line”.

Thus, it’s our variety that remains faithful to the original idea - here the outline, independently visible from the “whole” stuff, and there, the content, together with its subheading (in good outliners; I abhorr the 2-pane variety NOT replicating the subheading = item title above the content pane = one of UR’s many design flaws that kinook’s unable to acknowledge).

Of course, I’m not entirely honest here since I pretend our variety is faithful to the original whilst in fact, it diverts from it in another but equally important way: Whilst preserving the outline at any given moment - what “your” variety does not; you can’t access it by intermittance -, it doesn’t preserve the material in its entirety, in one pane - what your variety does, sacrifying… the outline!

So, in the end, our variety is not better, it’s just different, but the same goes for yours.

So from this intermediate result, we are at a par, concerning the rights to the name. And yes, I could now say, since our variety preserves the continuous presence of the outline at least - but reconstitutes the whole package in print or export only; besides, this missing functionality has been discussed in this forum here and then -, we have the better rights to the name. An additional argument would be, yours might be “inliners”, then, and not even the term is so ridiculous as it might seem at first sight, since “outlining” (I’m not a native speaker as we know) is something like “put the headings separate, independently of the final mix of headings plus material”, so, OUT of that total body. Whilst in your variety, these “outlined” headings, as a separate block, stay INSIDE the total block. So, this “inline” vs. “outline” hasn’t got the meaning yet I want to give to it, but it’s evident my creation isn’t absurd either, in “outline”, “outlining”, etc., yes, there IS a spatial connotation, too.

I’m not saying the 1-pane variety isn’t “outliners” anymore, but my objective was to prove that the 2- and 3-pane variety have at least the same rights to the term “outliner” as has got the 1-pane variety, and if one variety had “lesser” rights, it would have been the 1-pane variety. (“We” preserve constant accessibility of the outline, “you” don’t.)

III

There seems to be a little resurrection of the - otherwise almost defunct - 1-pane variety in smartphone apps; that’s amusing.

I hope people are aware the 1-pane variety is nothing else but another flavor of a folding editor, with all the limitations of that functional design. And I hope people are aware you can do heavy programming in the 2- and 3-pane variety of outliners; I do, and I’ll develop on it another time.

Here, let me just say that every language has its “comment line code”, be it “,” or “//” or whatever, and in your outliner, you make simply begin all your headings and subheadings with this special character, as well as any comments within the body text / within the contents pane; you script the “total (plain text) export” of your file (= tree, with interwoven body) into a file you then compile: Programming with a text file or several text files, but only as intermediate file to compile: No editor needed. And you’ll get all the formatting you want, you’ll get all the atomizing that you want (but not more than is reasonable), and if you want, you can use 10 levels of indentations in some very fractionized subtree, or just 2 levels of indentations in an “easy” part of your tree. Programming from within an editor is the best thing that was ever invented, and is much better than using Warnier/Orr diagrams (that technically leave a lot to be desired), for example. No need for pseudo-code (as in W/O diagrams), just put the real code into the body (incl. some little structure on the very deepest level only), but leave any “real” structure (= “designed” structure, in opposition of just “technical” structure, i.e. some if’s, conditions and such on the deepest level, without any further elements deeper down except for the most immediate ones) out of the content, but place it, as “commentaries”, into the “outline”.

For if’s, else’s, conditions, you need intermediate items, with subitems:

NOT

a
b if c

BUT

a
b c? (intermediate item; only by introducing these you will get forced logic instead of a succession of disparate steps)
—yes:
——blabla
—no
——d? (as above: it’s all about FORCING LOGIC)
———d=1:
————
———d=2:
————
———d=3:
————
———else:
—————
And so on, for perhaps thousands of items and millions of lines within the body, in big programs; ditto for many components, i.e. a-b-c is not necessarily a sequence; just introduce as many first-level “source” items as you’ll need for as many of concurrent program structures you’ll deploy. (And of course, only partial recompilation of such sub-programs is perfectly possible by proper scripting, e.g. “export” a first-level item = recompiles the whole substructure of that item only.

It goes without saying that you’ll do heavy use of “collapse all”, then “expand this item’s children”, but there is not a single other way you can bring “law and order” into programming that even could come near.

(W/O realizations are awful (B-liner is awful), but they opened op my mind to REALLY structured programming.)

But all this belongs into another thread and a B-liner review.