[Oberon] Re: Oberon digest, Vol 1 #49 - 2 msgs

[Charles Angelich]

>Message: 2
>From: cglur at onwe.co.za
>Date: Sun, 18 Aug 2002 22:40:14 +0200
>To: oberon at inf.ethz.ch
>Cc: cglur at onwe.co.za
>Subject: [Oberon] Re: Major feature undocumented & dir-info
>Reply-To: oberon at inf.ethz.ch
>
>
>Peter Easthope wrote:
>> cg> Peviously my comments about the "menu frame collapsed into
>> a dropdown menu for SystemFrame usage", got no response.
>> ..
>> cg> Let me now be more direct:
>> HELLO!!  Is anybody aware of this facility ?
>> 
>> No.  How do I see this phenomenon?  Is it in TUI
>> or in GUI?
>
>GUI { Desktops.OpenDoc }.   For n-o alpha 2001 try:
>1. mark SystemTrack   {F1}
>2. Desktops.OpenDoc SysTrk ~
>
>Now lets move on the the consequential question(s).
>Is it good that we have such 'unknown'  features ?

I will try to remember to do this in my N-O Beta.  I don't know
exactly what the problem is right now.

>And if not, how do we prevent this ?
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>> The output of "System.Directory  ...\d" can be filtered
>> with RX.  This is good way to find files with a specific 
>> date or range of dates.  
>
>This would be a good solution.  Charle's 1st format sequence:
>date, ID, size is best IMO, but messing with inner modules is a nono !

I disagree.  If there are errors, omissions, or oversight within the
inner modules they must be "messed with" before moving on to cause
futher dependenies on code that is not doing what it should be doing.

>If someone can put it in a wrapper, that's good.

The numbers of separate modules could be infinite but the code I refer
to within ETH Oberon is a very basic function of the OS that needs to be 
corrected or other future code that depends on these functions will become
an entanglement.

At present ETH Oberon is the only OS I can think of that does not line up
it's directory display within a proper columnar format.  This should have
been corrected at the time the code was originally added to Oberon.

>But what happened to the earlier version panel that I mentioned ?
>We need some discipline in this factory !!
>
>I await a final working solution.
>
>> Since RX was extended (Patrik R., Andre F. ?) to 
>> allow operation in TUI it is very useful.  While on 
>> the subject, let me ask this again.
>> 
>> Can anyone explain why the search has a scope 
>> of one line of a text file rather than the whole 
>> text?  This restriction prevents RX from making 
>> changes extending beyond one line.  For 
>> example, I believe it can not join every successive
>> pair of lines into a single line.  As far as I am 
>> aware this is not an issue of the theory of regular 
>> expressions.  It must be necessitated by an 
>> algorithm.  Probably I should study the source 
>> again but a little help would be fine. 

I don't quite understand your need to combine lines.  Could you
include an example of when this is necessary for a search/replace
to be effective?





Charles Angelich

The Ghost in the Machine!

DOS and W31 Tech website:
http://www.undercoverdesign.com/dosghost

Stories, poems, music, and photos website:
http://www.undercoverdesign.com/dosghost/faf