[Oberon] Is this bug acknowledged and fixed ?

[cglur at onwe.co.za]

I've tested confirmed this on Vers 2.3.2, 2.3.6, alpha 2001.
It concerns operations on a selected text string (eg.copy, delete),
after a copy from a text stretch spanning multiple viewer has
been done.

If the selection of the 'upper' viewer pair is not 'reset' eg. by F9
after the previous copy, a later copy-selected-stretch, is inconsistent.

Test by:
1. Use a text viewer with multi-screen-length contents as the copy
     source.   I use Edit.Open type viewer.
2.  System.Copy the source viewer.  
     Call the copied viewer 'copied-viewer'.
3. Edit.Open <destinationViewerToSystemTrack>  and set caret in it.
4. select 'start-stretch'  near top of source viewer and while MR-ing,
    hold down <Shift>,
5. select 'end-stretch'  from lower copied viewer by  MR and copy
  source stretch to destination by interclicking MM.
6. see the selection spanning the 2 source viewers copied to 
          <destinationViewerToSystemTrack>   and that the copied text
   stretch is still hi-lit in both source viewers.
7. attempt to copy various lines from the lower 'copied-viewer':
     this leaves the hi-lighting of the upper source unchanged, but
     correctly shows the new selection in the 'copied-viewer'.
     Dependant on the new selected position in the 'copied-viewer',
     the 'span starting from the upper source' is included (or not).
     Scroll further down to select a single line (while leaving the top
      source unchanged and hi-lit from its previous selection).

The apparent inconsistency is that after a "copy from stretch spanning
2 viewers" is done, the following "copy a stretch from the 'copied-viewer' ",
may or may not set the selection to begin at the 'top/original viewer'.

Also Edit.Search is inconsistent: not always finding the 'most recent 
  selection' -  when the top-copy is still hi-lit.

Using terminology of the old WordStar 'Block' operation;
since n-o does not show an already set block-end or block-begin,
I think that only the following contigious sequence should select
a 'spanning stretch': 
    A. select upper  
    B. <shift> 
    C. select lower.
Ie. after the completed 'Block' operation, both end markers should be
removed. And for further 'Block' operations, both end markers should be
appropriately reset.

This problem is analagous to the 'M$-ape simulation' mode where the
double left-mouse click activates (unintentionally).
As I remember microsoft has a time-out between the 2 clicks ?
With n-o: if I return the next day and set the caret where it already
is, I can get an unintended operation, from the second ML.
Fortunately F8 allows avoiding completely the 'M$-ape simulation' mode.

-- Chris Glur.