[Oberon] Re. PET ? IDE & syntax coloUring ?

easlab at absamail.co.za easlab at absamail.co.za
Sun Nov 26 03:52:10 MET 2006


> >This doesn't explain what e.g.  means:
> > Pet.Options	\UBC	instead of	Pet.Options	"0,1,2"
> 
Koen Desaeger wrote:
> This would mean enable auto U ppercase, auto B oldface and 
> auto C omment (sets italic font)
> ...
OK, thanks.

> There was no documentation for PET except the sources ... I had to check
> them myself to answer you.
> 
That confirms my repeated call for a wiki-type facility for outsiders to
be able to add value. eg. also documentation.

> Some useful key combinations:
> <ctrl> + T: delete to end of line
> <ctrl> + L: delete current line
> <shift> + space: select word at cursor
> <ctrl> + '*': bold face word at cursor

OK, except the first 3 would only be for someone who can't do
mouse chording, which IMO is a main feature of S3.
----------
> > I previously mentioned the advantage of syntax colouring.
> > The type that I've seen, is with coloured reserved words and special 
> > tokens ; and bracket matching hi-lighting.
> > 
Chris Burrows wrote:
> Colouring keywords and reserved words is not too bad. Where it starts 
> to get tricky is when colouring strings are involved, but at least these
> are limited to the current line. The trickiest part is colouring
> comments.  e.g. if you have just inserted '*' into your text, it has to
> inspect the previous character to check if it is a '('. If it is, it
> then has to scan and colour all of the subsequent text, possibly to the
> end of file until the next closing comment pair '*)' Conversely, delete
> an '*' and you have to check whether a comment has now been 
> removed or not. It would have to do this sort of processing on 
> every keystroke, cut and paste etc. etc.

I don't want to insert '*', but rather select <this is a comment>.
And I want to see inserted: "(* ? *)".
And I want the cursor to be at '?'.
Which N-O's existing PET editor already does, by code-completion.
I prefer the "select one of valid [displayed] choices", rather that the
 code-completion, approach.
Ie the editor should be constrained by the languages syntax, like
 a menu-tree is.

Hi-lighting reserved words marks the 'corners' of the construct.
I.e. if you can clearly see where IF, THEN, END are located, you
know better how the statement nesting is.
But colouring the whole statement, with all the adjacent nestings
a different colour is MUCH more powerfull.  S3 or similar users can
test it with 'wipe & dab'.    I don't know why I never used it before
when struggling with modifying existing code !

I'm evolving a whole bag of tricks to use linux-oberon, without 
which, a first time user may find linux-oberon non-productive.
I know that ETH insiders have got tools which they are hiding under 
the table.  How else could they put out the code which they do ?

> A phased implementation of syntax-colouring might be more feasible. I
> have seen partial solutions that are much easier to implement but still
> give useful feedback. e.g. the first step might be just to bold
> 'breaking' keywords e.g. RETURN, EXIT. 
> 
Yes phased implementation is always better where possible.
But my idea is not an extended editor, but rather a menuing-system.

> > As previously asserted, I don't see why 'keys' should be selected,
> > when 'whole constructs' could be offered. 
> > And the different constructs could be differently coloured.
> > But the nesting level would determine the colour, rather than the 
> > construct type.
> > 
> 
> I have this facility available to me in several development systems that
> I use (e.g. Delphi, Visual Studio, Blackbox Component Pascal but I don't
> make any use of it. Maybe my 30-year Pascal / Modula-2 / Oberon / CP
> programming habits are too ingrained, but, even with my two-finger,
> one-thumb typing technique I find it quicker to let my fingers
> automatically type the constructs instead of having to jump around in
> pre-defined templates. Remembering all of those shortcuts is a 
> challenge as well!

The need to remember anything is a no-no.
You should only have to *recognise* and select. I.e. menu driven.  
For me, it's all about leaveraging the existing fantastic S3 interface.

I've got 5 versions of N-O [v2.3.2,2.3.6,2001-beta, LNO,linux]
with multiple copies on various disks, partitions, which all are usable
'objects having their own knowledge'.
Potentially great chaos, except the unified key is that they all keep
their 'latest status' in the 'same place'. Who's name I don't need to
remember.  Humans especially left brain engineers remember
space and colour naturally.

There's a 'corner' on the screen, who's name I don't need to 
remember, since S3 doesn't require me to key-in. But I can grab
it to show you now [by cutNpaste]. It's called "System.Log".

So for all my 20 odd, still living S3 installations, if I need to ask
"what's your current status ...what project did you last handle..?",
I just need to run the version and 'look at the special-corner and
*think* open-the-text-corresponding-to-that-corner' and the
file:System.Log opens for *this* installation, with the info.

Use factoring to try to reduce mental load ?

--snip --
> 2. A Procedures Index (Similar to 'TAGS' functionality on other systems)

What is 'TAGS' functionality ?  I've seen it repeatedly cited lately.

> When working on a source code file, an alphabetically-sorted list of
> procedures is automatically maintained in a separate window.
> Double-click on a procedure name and it automatically takes you to the
> definition of that procedure in the source code file.
> 
> 3. An Imports Index
> 
> An alphabetically-sorted list of imports in the current source file is
> automatically maintained in a separate window. Double-click on an import
> name and it automatically opens the corresponding source file in a
> separate window.

Having these close at hand is great, provided no screen area is
permanently allocated to them.  That's one thing about colouring: it 
adds intelligence without consuming extra screen area.
------------
The existing S3 tools Watson & Columbus are a great help.  Similarly
a syntax driven editor [table driven, for adaptability to several
languages - these days you need to borrow from several languages:
 C, python, java ...] would drive productivety IMO.


== Chris Glur.



More information about the Oberon mailing list