[Oberon] ETHO work flow tools.

[eas lab]

It's quiet likely that others have discovered this little quirk,
without mentioning it: a serious flaw in the work-flow model of ETHO.

Analysing why A2 doesn't work for me, led to recognising a similar flaw in ETHO.

My ancestors wrote on the cave walls. Later in Babylon they wrote on slate &
clay-tables. And then they had the mess of a zillion papers and chaos. Like me.
Until a saviour arrived and suggested that:
 make all papers the same size [compatible];
 number/ID and pysically order them meaningfully;
 bind them together [with a hinge];
 add a table-of-contents, to a unique, heuristically chosen location;
   and we'll call it a "BOOK".

Novels have a linear structure, and could be contained in a scroll, because
they don't need RAM. "Knowledge" OTOH, is heirarchically/tree-like structured,
and needs RAM; which a "book" achieves.
===========

ETHO S3 largely achieves the superior discipline/constraints of a book;
 whereas A2 is the same mess as Microsoft Windows.

Although I did some substantial software projects in the Turbo Pascal
[and before that] days, I can't cope with ETHO. But now I've found out why.

As the complexity of the project expands:.
the number of textFrames opened increases and it's inevitable that
a critical one will be Grown to cover others.  Once that is done, choas
will set in, since inconsistent copies of 'papers under the pile' will be
created..

IIRC TurboPascal [for DOS] showed only one textFrame at a time, but there
was a stack-menu of recent textFrames, which prevented the described problem.

Interestingly, `wily` [the public domain version of Plan9's acme] which
acknowledges being based on ETHO, seems to have anticipated and handled the
described problem. Eg. if you've got testFrames A,B,C & you <Grow> A to cover
B & C, and then later <reload> B, then the previous <Grow> of A is reversed
so that the already loaded B is visible. I.e. the *existing* B pops out.
==
Apparently ETHO has anticipated the problem too, and gives the solution of a
<popupmenu>: but IIRC it caters for only *.Mod, *.Tool files, which restiction
seems bad. Perhaps a 'separate-class' can be created for other file-name
extensions. BTW, a serious problem with LEO is the hiding of the filename,
due to the field length overflow by long path-names. `mc` handles this
well by showing the rightmost/most-relevant text. How does A2 for Win & Linux
handle this problem of showing long pathnames in a restricted width field?
==
Rather than the technical details being  the limiting factor,
it's the human work-flow aspects that are important in computing.
Apparently one can be working away for years, without seeing the bigger picture.
"Just get on with the job" is a disasterous short-term attitude.
==
Doutlessly the BIGGEST picture is keep-it-simple, ie. limit the number of chunks
that the user has to keep in mind at one time..
A menu condenses N items into one. A book disciplines N pages into one.
..
== Chris Glur.
..
PS. I've just been looking at a LEO file <TextPopups.Tool>
which may have come from ETHO, or been partially created by me,
which seems to handle many of the problems raised above.
Apparently this fix was introduced late in the evolution of ETHO.
How did the Turbo Pascal designer manage to solve the problem 20 years earlier?