[Oberon] English translation needed.

easlab at absamail.co.za easlab at absamail.co.za
Sun Dec 4 05:17:00 CET 2005


When I first read this, I remember thinking that it would soon 
'come to be naturally'.  But it didn't !

ETGuide.Text reads: ----------

ET.Marker set spec [spec = saved | this | x-number y-number]
	Sets the marker (star pointer).  spec indicated the position.
	- ET.Marker set saved
		The frame, at the position marked with ET.Marker set
		saved, will be marked with the star pointer.
	- ET.Marker set this
		Marks the frame in which the command was executed with
		the star pointer.
	- ET.Marker set 800 225
		Marks the frame which contains the coordinate 800 255.
-------- end of ETGuide.Text extract -----

This documentation is BAD !!
Not because an insufficient effort was initially expended, but
because no mechanism is in place to improve it over time.

There are 3 cases demonstrated.
The case:  'ET.Marker set 800 225' is most intuitive and
  should have been listed FIRST - not last.

An overview [the ability to access parameters from text-frames
(the black-board method) is needed by ETH oberon because ....]
should be given.

Re. 'ET.Marker set saved'
Q - If a 'position' ie. the empty user-track can be marked,
    and a frame can be marked, does the frame's-mark stay
     with the frame, when eg. the marked-frame is moved to
     the alternate track ?  Ie. does the mark belong to the position
     or the frame ?  Or perhaps there are only nested-frames 
    [and no positions]; the mother-frame being the screen ?

My experience is that the screen position is marked, and if any
activety on the frame makes the mark [star] invisible, then the
position becomes unmarked.  And since there is only one marker,
it is active only when it is visible.  Is this wrong ?

Can someone give an example how 'ET.Marker set saved'
would be used ?

== Chris Glur.

PS. this matter relates to a newsgroup debate 
   re. Menu-input vs. command-line-input.

I say, the freedom which CLI advocates love is bad.
Menues discipline/limit your choice = good.

The worst/most-absurd is the proposed 'speech' input.
If informal communication methods sufficed, we wouldn't need
  mathematics and musical notation - which have evolved over
 thousands of years.



More information about the Oberon mailing list