[Oberon] Towards a syntax directed editor: IDE

[eas lab]

aka Old-paradigm rediscovered.

The new paradigm/illusion, about 50 years old now, is
commumicating via written memos, with little-man-in-box.

The original/valid view of computers is of a multi-dimensional
switch.  All this talk about "typing and fingers" is absurd.

The old railway-diagrams vividly emphasise that at all stages
the next valid token is one of only-a-few;  which is most
economically [in effort] just selected from a menu.

For new users, to see what few steps are needed: ----
Desktops.OpenDoc Find.Panel ~
use: reserved word    *.Text
=> gives: Oberon.Report.Text   'served words listed below.'
shows there are only 4*13+8=60 reserved words in Oberon.
--- end of 3-step-log-demo for new users---

AFAICS, the only time for typing-and-fingers is for the
special event of the user THOUGHTFULLY inventing a new
identifier.  Once invented, the identifier can belong to
the menu, which could/should also be 'scoped'.

Which seems to me to give a syntax-directed editor?

Imagine each new language just being entered into its
own data-file.  Syntax coloring by several editors already
are a step towards a syntax directed editor.

Perhaps this won't work for dirty languages like bash or
C++.  How do dirty-languages manage syntax coloring?
'lisp' would be boring?   Or perhaps not !

My simplest imagined input, for ETHO is that the token
at the cursor [not caret, which requires an exta clik] is
copied/appended to the source-text.
The caret is an extra dimension and has memory and
need not be wasted when the cursor will do.

Q. does any ETHO code, other than <placing the mark>,
use 'the cursor'?     I want to copy existing code.

Pet.Tool already gets close to this ability, with:
}  <shift> + space: select word at cursor
}  <ctrl> + '*': bold face word at cursor
In fact it needs the caret and not just the cursor.

I imagine:
 any-key-DOWN hi-lites the cursored-token,
   which can be viewed for confirmation before,
 that-key-released copies the token to the destination.
So Pet seems to be a good starting point to evolve test code.

But, LEO gives me only: System.Directory Pet.* == Pet.Obj
And then LNO gives me only Pet.ReadMe and my rather big
set of 357 *.Mod files in their separate partition of N-O
has no Pet.Mod

Q. was/is Pet.Mod available ?

Of course it would be extended to copying whole structures from,
the menu, corresponding to eg.
Statement =
[ Assignment | ProcedureCall | IfStatement | CaseStatement | \
WhileStatement | RepeatStatement |
ForStatement | LoopStatement | WithStatement | EXIT |\
 RETURN [Expression] ].

I find the railway-diagram-representation more intuitive.

Of course this whole idea is already CONFIRMED by ETHO:
you don't piano-play the keyboard like a journalist/novelist.
You select, visually recognised [bigger than keys] items and
assemble them. Let's just extend the good, proven method
of ETHO.

== TIA.

Please criticise my idea. Early abandonment saves wasted effort.

PS. LEO & presumable other ETHO has a nice
-> System.Directory Scheme*
which seems relevant to, programming via
<selecting from the language's initial builtin list,
and then from the evolving definitions>.
PSS.
Q. Is Scheme*.Mod available?
How much ETHO source is hidden?
Is there any policy that contributors' code must be open
to be included in the distribution?
PSSS.
My thread about ARM:ETHO was not about hobby-size
micro-controllers, but about: can we escape the WinTel
monopoly and still have the magic of ETHO.
It's the proven HumanComputerInterface that's important.