[Oberon] Mouse chording?

[eas lab]

Previously I've mentioned wily:
 the public domain version of Plan9's copy of ETHOberon.

Unfortunately wily's Left/Right mouse is reversed w.r.t. TextFrame:Up/Down.

I've patched the C-code on my X86 version to be like ETHO.
My rPi version, which I use less often is still <reversed>.

Like ETHO, wily uses Middlekey to execute.
My current mouse is especially problematic, since mouse:M is not atomic.
Ie. it may be: M down, cursor move while down, M up.

Vaguely I had the idea that ETHO captured M on the up-stroke, thus.
eliminating this problem. Is this the case?

Interestingly the rPi seldom has the problem. But that's for the same reason
that old-Turbo-Pascal can't run on new hardware, which is too fast for the
particular quirk, that relied on delay/s.

It seems that wily is trying to be too smart:
  whereas ETHO knows <M on a token/P.M>,
  wily also knows M-down, wipe the string-of-tokens, M-up.

I'd prefer to sacrifice the <wipe the string-of-tokens> facility,
to get better reliability [fortunately, like ETHO: bad commands are immeditely
indicated]; but I fear that there are complexities which I'm not aware of.

Is the original mouse chording scheme/theory documented ?

Is there any obvious problem in replacing the:
 M-down, wipe string, M-up,
with
 LMR-down, wipe string, LMR-up ?

== Chris Glur.

..
]The 2013 edition of Project Oberon, running on an FPGA board such as the
]OberonStation, is a working and available example of a system built
]entirely from scratch with the express objective of making it easily
]explainable and understandable in all aspects.
]
]And if you really want to understand something, you have to try changing it.
==
The ability to modify and observe the results, is the essence of SCIENCE.
A football, a hoola-hoop, a diamond are not very modifiable/programable.

Stuff that you buy is yesterday's [3rd world] story.
Today's [1st world] story is health and knowledge.
What do medical surgeons use to train on these days ?