[Oberon] N-O: editor's 'global' search-string incompatible

easlab at absamail.co.za easlab at absamail.co.za
Sun Feb 8 13:31:34 CET 2004

How many n-o users are we ?

That this may seem a trivial refinement, is because n-o is already
so matured and well tuned.

A search-string may/should be conveniently searched for in different
text-frames by just repeatedly activating the 'Search' of the
various frames.  

Apparently the 'last search string' is retained in a global;
a convenient default, like the 'last deleted string'.

That this global [last search string] differs eg. between the Edit.Open and
Desktops.OpenDoc  frame-families is unfortunate.
Not so much because the user looses the efficiency of not having to re-set
the 'search string' when going to an incompatible (from the previous 
frame) frame; but that he is likely to forget that his assumed 'search string' 
is  invalid.

Serious errors can be caused, because there cannot be an error
warning.   Ie. he may base important decision on the false belief
that <search-string> is NOT in text-frame X.

A similar/opposite problem  which is confusing for the beginner
is that the find-utilities insist that "Oberon10.Scn.Fnt" is in the 
file.   This appropriately invisible string, being part of the 
header-formatting-info is less likely to perpetuate false decisions than
the original mentioned quirk (eg. mistakely insisting that: "your email does
NOT contain the <string>  - possibly in the High Court !).

When/if you go the fetch <search-string> (eg. "Oberon10.Scn.Fnt")
you will soon find, it's not there, but won't make false claims about
a string being absent.


Is it  a problem in future versions to have the same global search-string
 in all editor types ?

BTW there are good reasons why a user would want/need to use both
(incompatible in this minor respect) frame families; 
eg. Desktops.OpenDoc doesn't do ' TextMail.Cite * '

With the rapid cut-n-paste facilities, it's quiet practical to move a 
text-strech to a diiferent editor/frame-type, just to use a certain
facility.   A bit like unix, rather than hoping for the editor which 
does everything.  Modularity & evolutionary refinement is best.

== Chris Glur.

More information about the Oberon mailing list