Forum Posts Feed
Outliners vs. Inliners (and a little intro to programming with Outliners (but not Inliners, sorry, Steve!))
< Next Topic | Back to topic list | Previous Topic >
Posted by Fredy
Sep 1, 2012 at 08:51 PM
I
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.
II
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.
IV
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.
Posted by Alexander Deliyannis
Sep 3, 2012 at 08:34 PM
Fredi wrote:
>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.
Where do you do this? In a dedicated IDE or a programmer’s editor? Or in a classic editor that organises syntax? I recall an outliner called Leo http://webpages.charter.net/edreamleo/front.html which is aimed at programmers.
For me writing in a simple editor and being able to mark the structure as I go along by comments could be ideal, but I can’t think of a program that can do this, with the exception of Sense which uses keyboard shortcuts rather than markup.
Posted by Stephen Zeoli
Sep 3, 2012 at 10:55 PM
Fredy,
This is largely a matter of semantics. You claim your “true outliner” is the tree pane in a two-pane outliner. Fine. That means the whole piece of software, content and all, is NOT an outliner… at least by your very definition… just the tree-pane is. In most cases, the tree-pane in a two-pane outliner is not nearly as flexible and easily editable as a good single-pane outliner (admittedly, there are not many of those).
As you point out, the origin of the outline is a focus on the structure and logic of the topics. That’s what a one-pane outliner forces you to do.
I believe, however, that a one-pane outliner with inline text makes for a better writing environment, because it treats your project as a single document, not as a collection of documents. The problem with my approach is there is no application that does a good job of it. If you were to read my article about GrandView, you’d see what I’m talking about. GrandView allowed you to keep the content separate, as you prefer, but also allowed you to see it inline, giving you the best of both worlds.
I don’t really understand how a two-pane outliner helps you to be more oriented in your “neighborspace” than you would be in a one-pane outline.
I’m actually not in charge of what people call their software, so if you want to call two-pane outliners true outliners, I honestly have no objection.
Steve Z.
Posted by Fredy
Sep 4, 2012 at 09:10 PM
Short Answer:
Steve, I tend to believe that you are right, and that for writing, outliners(1) / Word are better suited than outliners(2/3). What’s needed then, is a good outliner(3), with good inline capabilities, incl. shifting around outlining levels between tree and content in both directions.
Detailed Answer:
(don’t read, don’t complain!)
I
Steve, you’re perfectly right, 2-/3-pane outliners are outliner-driven working environments, and I perfectly see your point here: I extrapolate from the core element to the whole, you say the whole is something else than its core element, and should hence be named otherwise; indeed, people doing this on paper, in “ancient” times (or in school, today - given they don’t work on slates, yet), do their outlines, PLUS their text, and do not call the whole an outline. On the other hand, we must distinguish between “outline” and “outliner”, and an “outliner” would be a technical system creating “outlines” (among others, i.e. the text body, and perhaps further lists). I see this playfully, not the way hardliners see the world and its functioning, and I would be very happy to leave the term of “outliners” to the 1-pane variety if somebody came up with a short, crunchy name for our thing.
II
The irony here is that I’ve adopted outliners(2) after adopting askSam (with on-the-fly outlines by “fields” you choose, one of the greatest ideas in IM ever, but not developed further (problems: their system ignores but the very first entry in any given multi-entries field, and ditto for any but the very first of multiple identically-named fields, so both ways it leaves out any alternative “tag” of several tags an item might have - this limitation might appear minor to a non-AS-user when in fact it cripples the whole system: those “fields” in AS are THERE for containing many such “tags”, and there is simply no way to have an alternative look on your material but by search hit table, not by tree building, and finally, this tree building takes ages when you’ve got too many items, i.e. for big databases, there is the indexed “professional” version, but the processing of the on-the-fly tree building does NOT seem to be enhanced by that indexing (for search) in any way) - had AS built on this finest feature of that sw, AND had they done away with innumerable bugs, it would be the very best IM system under several thousand dollars I’m aware of - hence my anger about it being laid into the hands of the marketing director who year after year didn’t do but marketing speak to all those loyal customers complaining in their forum about the bugs, etc. - whilst real development had come to a halt years ago.
So, tree-wise, LOTS of better things than exist today, could be done, but this is rather demanding, programming-wise. But I spoke of irony. Well, the irony is that I came to AS then to outliners(2), after having realized - I spoke of it here a year ago - another IM system that was NOT an outliner in the strict sense of this term, not 1/2/3-pane: I didn’t use 3rd party components but had to do which what I was technically capable of, within ToolBook’s programming language, and so I did multiple cascading panes containing just ONE level within the tree, i.e. siblings (and additional panes for multiple parents, multiple cousins, etc.), and my multi-mouse click system (detailed here and in MI and UR fori) then assured that with l/r/d-clicks on the first fourth, middle or end of an entry there, the sub-items of that entry were shown in the same, the “next” (in a row 1-4), any particular of given 1-4 (by menu and also available by Shift/Alt/Control-Click), or a “standard” pane, etc., and similarly for the parents of any item in such a list (“parent” meaning “natural” parent, but if there were also “adoptive” parents, a little menu popped up); items having sub-items were automatically marked up with a special sign indicating that.
This was an incredible “flee flow” of many different clusters, and navigation was made easy by automatic coloring the background of the panes / item lists, and I even had toggles (state indicated by colors (bright vs. washed-out versions of the same color indicating other things) to assure that a normal “Enter” pressing would show the “children” in this or that pane (and of course, two sets of fields for two items at the same time; many “record fields” = a flat database with superimposed “tree”). As said before, because of instability of the programming language (not of my program), i.e. bad memory administration, I couldn’t get it stable above some 6,000 items - I’m in the 6-digit numbers now…
I had programmed an internal tree, i.e. each item had exactly ONE natural parent, and I had routines checking for this (no deletion of an item having “natural” children; similar for renaming, similar for transfer of “natural parenthood” (= not “adoptive parenthood”) to another parent, and in these, I had routines preventing recursion (recursion was allowed for “adoptive” things, but never for “natural” things.
I had also programmed an export tree, i.e. for export into Word (6.0!), the programme built up a (partial) tree from everywhere, but similar to AS’ trees described above, and since tree building implies non-recursiveness, this automatic tree-building on export only included (= by definition) “natural” parentage.
So the irony here is, finally, that in the system I realized, a virtual tree was always there, was automatically maintained thru any given process, as a special, strictly hierarchical structure among many others, “associative” - I relied very heavily on clones, there, since I was so much in love with my own creation, so I couldn’t put things into too many different contexts / virtual collections, or so I believed then! -, AND a tree structure for export… but on screen, I never saw any real tree in my own thing!
On the other hand, in my tree-free display system, I very well HAD alternative, underlying tree structures, i.e. from my “adoptive parents”, I could trigger alternative tree structures, although flattened-out as in the principal tree structure based on “natural” parentage. So, anybody will easily get that AS’ virtual tree structure, years later (from AS 6.0 on), had ultimate power on me, and you also will understand that with today’s outliners2, I’m angry that their developers don’t do alternative tree structures (it seems that in CT, there should be possible such a thing, with lots of manual work to get to it, not in any way at least semi-automatized if I’m right).
When I’m speaking of 4 “normal” panes in my system (= for 4 consecutive “indent” levels or perhaps for 2 different sub-trees, each with 2 “indent” levels, or whatever), I leave the special PM pane out, i.e. the very top pane “deciding” which “sub-trees” will then be shown in pane 1 - thus, I HAVE HAD, in the late Nineties, such a complete system, WITH PM, WITH clones, even WITH automatic adding amounts of items in their parent items (had a “recaculate” function for it; cf. B-liner) - and it was hoisting in perfection, without me being aware of the term…
So, when I did all this 15 years ago, with ToolBook, I cannot believe my eyes when I see how real programmers do in 2012 with all what’s at their disposal today, e.g. components. In view of this, MI has done “lots more”, with its tags, than UR has done, but lately, neither of them seem to do much…
(From the description of my system, programmers will deduct there was an incredible workload in my system since any rename, any move, etc. triggered endless checkings and updates of lists in recordfields of often many, many other items; on the other hand, all these routines could easily adopt to a real database…)
III
So, with all I want from such an IM system, how could I ever think an outliner(1) will do even 20 p.c. of what I’m asking for? And, as said, I never made that strict discrimination between “writing” and “stuff / material”.
You ask, how can I be better “positioned” (my term) in my environment, when writing, then I’d be in continuous writing (my assumption, you said in an outliner(1)). You say, outliners(2) make a “collection of documents”.
It’s a good question, and a “false” assumption (ok, ok, semantics encore, technically you’re right - but conception-wise, these are not “documents”, no “aggregation of stuff” but “atomization of stuff”). In that UR thread (first part of “proper outlining”), I explained why it’s reasonable to fractionize your material for some dozen of pages, into perhaps 200 items (of course, you need hoisting or different files). So, I do NOT see such items as “documents”, just as “bits”, quite as in the “margin numbers” in legal textbooks - 1 margin number, 1 bit of text - and I even devised a cross-referencing system allowing for cross-referencing these bits in writing, but for publication purposes! Which means, whenever I move such a bit (= item), the reference to that moved target will stay the same, and before publication, you run a routine that will update all these references. In other words, “scripting from the outside”, I simply cannot implement a real system here, doing the updates on-the-fly, but at least, you can use special codes that are then “normalized” when your work is finished (afterwards, you could do more codes, for additions, etc., but there would be some manual adjusting - or more scripting needed, which is to say, better run the “normalizing routine” onto a “publication copy”, and continue any further text editing within your original text body where all references are in their original “chaotic” way).
In 2011, I asked UR for such a system, built into UR - not even got an answer from them. Where’s the interest of such a system? Well, let’s have a look upon the most advanced of such reference systems, in MI. There, you can do something which is not possible in competing systems: You can reference a paragraph!
Here, we are in agreement, if you got perfect paragraph referencing, you don’t need fractionizing your text into separate bits of text so desparately!
But this paragraph referencing in MI is for your screen work only: Try to export any such functionality into an export format for publication: You’ll fail, nothing is provided here!
And that’s why we need, if we use such an IM system for ultimate publication purposes, one of two things:
- A system, hopefully built into the IM system, that is automatically updated when you work, or at the very least, that is “normalized” when you finish your work for publication. OR
- Here, anybody{>23} can do this, a system that just does codes into the text body, then, upon pre-publication work, will be translated, by a dtp sw, into real references TargetExample{<23}; this is possible since such dtp sw are able to fetch the corresponding heading / sub-heading and / or its final numerotation.
I concede that the second alterntive is the better one anyway, since it allows for referencing without forcing fractionizing in writing - but I like this “margin number” system so much that I like to have those bits listed to the left! Which makes it a question of style, of preference.
IV
a)
What is this “positioning” advantage I claim? It’s the “fast-look: discarded!” thing. If you “store” your different thoughts under sub-headings in a separate list, a short glance will show you what, and in which order, has been treated, in this “immediate neighborhood” you’re moving at this moment, whilst, when you do the intersection within the text body, you must scroll up and down (I explained this in detail in that UR thread), and you lose focus - whilst with the “list view” system, you only lose focus if you check some of these, i.e. their content, but you don’t lose focus just by visual checking (existence, order).
b)
My system absolutely need QUICK creation of a new item, VERY quick creation; in my system (with macros), a new “sibling”, or “child”, is just ONE key away, plus its title, i.e. the sub-heading I would have needed to type anyway, AND it’s away without no response time whatsoever (= in UR a big problem, at least on not so fast pc’s).
c)
My system presents another advantage, I’m able to “mark up” these bits, by formatting (bold, italics, underline, coloring), and also with code chars, for ToDo’s (“look again”, “search source”, whatever) - of course, you can do the same within your text body, but I like the body to be neat, so I like to mark up the ToDo’s in the tree = item list.
d)
Speaking of AS, in AS Dos, up to the latest Dos version (5.0 I think), you couldn’t get more than (I think it was) 1,000 chars in any single item (incl. “fields” containing tags or other standardized info, etc.). This was a rather singular writing experience in these times, since I came from Wordstar, WordPerfect, Euroscript (!), where no such self-limitation was due. I remember very well how awkward it was to segregate bits into two or more such items, then link them together (= terrible, and not really functional!). But it could be that my “preference for splitting up” was born in these years (I had all my stuff in Dos-AS when I did my IM system then, since AS-Windows was abysmal).
e)
I’m perfectly honest here, so I confess that most of the time, I do NOT the “new sibling” key fast enough, but write “over into the next sub-subject”, THEN do the ^x, new sibling, ^c… But then, I have a sharp look if in some bits, I entangle two bits or more, and reformulate and dissect again. So there IS a purpose in this, but that could be achieved within the text body, with doing the corresponding sub-headings there.
V
Hence my conclusion:
1) I’m inclined to admit that my “discard to the list” stance is debatable; even I don’t formally oblige to it but ex post, which means, even I do “naturally” otherwise than I preach.
2) I’m formal, why have one system for writing and one system for “collecting”? Have never found anything attractive in such unnatural setup (cf. the other thread). Perhaps we continue to disagree here, but then, automatic referencing forth and back, from material to writing and the other way round, sort of synching, should be needed (and will never be there - we know how little today’s programmers do for their own programs, so for interaction with competing sw - nil).
3) It follows from this: People asking for “inlining” within the content field of outliners(2) are RIGHT.
AND it should be given to them the possibility to “export” that outline(in), for as many levels as they want it, to the tree (= e.g. 1st and 2nd level of their “inline” becoming 5th and 6th levels of their “outline”), and vice versa (= e.g. deepest or deepest and second-deepest level of “outline” becomes their inline - now assure that this even functions with existent content, which in our example would become level 3 (remember we’ve multiple items with their content, poured into just one item’s content field here).
We’ve just found out why we’ll never have proper outlining - the concerned developers don’t follow us - as I said in the UR forum, for CRM and specialized lawyer sw, there are big markets, big money available, and some development is going on - but even there, it’s not in adequation with all the money they could spend on developing… So back to outliners…
Anyway, a good outliner(2) (that’s an imposture: a good outliner(2) is an outliner(3)) does it all, the good “flow” writing experience, AND it holds your stuff, whilst an outliner(1) forces you to store your material elsewhere, and I simply don’t think that’s convenient, for quick accessibility / scope reasons, both-way.
(And we didn’t even mantion all the external referencing stuff, that also should ideally be included into a really good IM system…)
P.S. There are SOME of these systems. Nowadays, on the compuses all around the world, these systems are free or cheap for students, often financed or co-financed by the university. These systems must be distributed by much higher numbers than all “outliners” in the world together are. From a marketing pov, such a system should be developed into a real IM system, including everything “outliner” afficionados would want - AND they could be make big money afterwards, when postgraduates adopt the commercial versions within their businesses, instead of “Word”. But from a motivational pov, this will never happen: Fractionalization of sw categories.
Posted by Fredy
Sep 4, 2012 at 10:24 PM
Alec, if I misunderstood your question, reformulate. As I understood it, I can answer as follows:
In any outliner(2/3), I structure all my stuff as I would do in a W/O diagram, or you can even do the same within a program like MindManager, or even within a W/O diagram (but not with B-liner, but perhaps with MindApp, same developer). Problem with B-liner is, you only have 80 or 100 chars for “footnotes” for each item, whilst you need a real “note” field, for doing the “real code”, i.e. the routines - no need to bring the W/O system to excessive details, you can perfectly do routines, with 4, or with 80 lines, as compact “notes”: W/O diagrams are good for the overall structure, but if you find yourself with thousands of W/O items (even distributed on many sub-diagrams), I think you did “too much”, especially so since W/O isn’t real code but pseudocode, so trying to follow with W/O into the “body” level of a program seems a lot of unnecessary work to me. Structure: tree / W/O; routines: “notes”.
Then, you will have the structure within the tree, be it a vertical outliner’s tree, a horizontal W/O tree to the right, or the horizontal “mindmap” tree (also to the right) within MindManager or your Mind… what’s it called again. The important detail is, it should allow for plain-text export as is possible in most outliners, with all headings / subheadings / nodes of any indentation level immediately followed by the corresponding “note”, i.e. not “notes export” separately (and that’s why I don’t know if the W/O diagrams in MindApp will do; I spoke to B-liner’s daughter (I think), and she said B-liner will NOT be enhanced in any way in the near future, so if MindApp doesn’t allow for this way of export, any automatted W/O diagram will not be available).
Then, this complete plain text export will, by scripting / macro, straight go into a text file, like a text file you would have created with an editor, but WITHOUT any editor use! Yes, I tout editor use, for other things, but not for programming!
Thus, you’ll have a plain text file (whilst in your outliner, in MindManager, or something, you will have formatted text, just as it pleases you there in order to better structure your program (components), and, again by scripting / macro, you’ll compile it.
From your “production tool” (outliner, mind map sw, whatever), you will “export”, as said, but need not export the whole thing, each time. If you have a big application in one such file, you’ll first select your “main topic” / “source topic”, do your trigger command, and several seconds later, your target program will be compiled anew - no switching to any editor or such needed, just export into file, then compiling.
And if have any fractioned program to develop, either you do it with several outlines / mindmaps / W/O diagrams (if MindApp works as hoped for), or you’ll have one central such mindmaps, etc., and do the “export and compile” command from the item in question that is the source item of that separate file or the sub-mindmap or whatever - have the same trigger command trigger the same procedure from any such - original or intermediate - “source item” = source item for the big subtree of that item in question that the “export” command will build up.
When your projects develops, you’ll place the initial consecutive A, B, C:
0
-A
-B
-C
under an intermediate “1” and begin an intermediate “2” for a second program component:
0
-1
—-A
—-B
—-C
-2
—-A
etc.
Then, you select “source” item 2 and trigger the “export and compile” script / macro.
This is perfectly possible in a network since sw like UR or MM are network-ready, i.e. anybody could trigger such partial recompile commands from within those parts of the “overall tree” being available to him.
If you don’t like all items (= items’ titles, the nodes in a diagram or the items in an outline tree) beginning with a comment char, you can easily extend your script or set the options in the export function of your design tool in a way that any such heading will be preceded by exactly the comment char of the given programming language; such an automatism will make your diagram / tree even neater in its appearance, whilst it takes the option from you to have a mix of pseudocode and real code in these items, but perhaps it’s a good thing to avoid such a mixture in the first place, so in a sub-routine’s title, you would write “while a > x”, which would automatially be preceded in export by “//” or whatever is needed to comment that line out, and as first line of the “note”, you’d replicate this “while a > x”, not the least for better understanding the 60 lines or so that’ll follow within that “note”.
It goes without saying that there are numerous projects in which you would need several programming languages, all with their specific comment chars, so in the end, putting the (adequate) comment char right into the item’s title would perhaps be preferable, but then, you’d probably only trigger “export and recompile” for one such component with one programming language, so it would be sufficient to put the adequate code to the respective source item, then having a routine replicating that individual code onto any subsequent (“child”) items.
I know that in this scenario you don’t have automatted formatting, etc. for your specific programming language(s), but you can do lots with scripting and text expanding, be it for “difficult to remember” commands, be it for 1-key typing of commands very often needed; remember in scripting languages you can use global variables, so it’s possible to have just some keys but dozens of such pre-figured commands at your fingertips.
I must make a reservation: My system will not function with programming languages where indentation levels of the code is a constitutive element of the program syntax itself, since my system simply doesn’t care about indentation levels of the code, and chances are if you have a look at the straight output, via opening the text file in an editor, it appears horrible to you. But then, you will “never really see” this horrific intermediate output, since any debugging is then done back in your production system (you’ll just have a look into what the debugger presents you just in order to identify the place to look into, within that production system).
So much for MY system. Of course, you can optimize it, with more scripting (or just simply by checking more options in the export function), so that the intermediate file, that will then be re-opened by the debugger, will have correct indentation, blank lines, etc.
So, if your question was, how to assure that the debugger will “open” your production system at the “right” line, I’m sorry, that would need LOTS of further scripting. But for me, its perfect for everything I’m doing, and I even put my ancient programming into such a structured system (in order to contemplate, and perhaps to re-use lots of the structure of that code some day).
I particularly savor, except for the extradordinary structurization (which in a collapse editor is not possible to this point, or let’s say, not as evident there), the fact that I can freely format my code, which I heavily do, in the tree and in the body.
I concede that better debugging facilities (= without the necessary step of looking up the incriminated lines, then search for them within the production tool) would be very welcome, but then, just compare my system with original W/O:
In W/O, you necessarily do DOUBLE WORK, any change within the graphical represenation must then manually be replicated by hand, within the body (= editor files), and vice versa, which is very time-consuming, very dumb work, and very error-prone. My system isn’t perfect, but all is done within ONE production tool, not in two that must endlessly be synched by hand.
(As for automatic synching, of structure AND content - synching just structure would be devoid of sense -, between, let’s say, UR and VisualMind, well, I kindly explained the interest of such interoperability to both… and never get an answer from either.)