Forth Edit Task
Volume Number: 2
Issue Number: 11
Column Tag: Forth Forum
An Edit Task for Forth 
By Jörg Langowski, MacTutor Editorial Board, Juri Munkki, Helsinki,
Finland
An Editor Task For Mach2
By Juri Munkki, with Jörg Langowski
[Since this column is the Forth Forum, we must give others space for
contributions. This month we received an article by one of our readers, Juri Munkki
from Helsinki, who devised a rather practical text editor to run under Forth. Evidently
they lack a desk accessory editor like MockPackage+ which will run with HFS. With the
multi-tasking Mach2, an editor task helps a lot in developing programs; I had the same
problems as Juri trying to use Edit 2.0 in connection with Mach2. Mach2 and Edit just
don't want to run together under Switcher - even with the cache switched off - on a Mac
Plus. Also, Edit is overkill for Forth development since individual program pieces tend
to be rather short.
The 32K text size limitation for this editor is therefore no big drawback; in fact,
it is more than the 28K of MockWrite. Read the code carefully for some interesting
additions to Mach2, like ON, OFF, ANEW, scrap handling words, an on-window palette
menu and auto-indentation on text entry.
Enough of a foreword, I'll pass the keyboard to Juri now. J.L.]
Editing a Problem in Mach 2
Mach 2 is a great language, but it certainly has some flaws. The first one that
every programmer confronts is the lack of an integrated editor.
Palo Alto Shipping suggests that Edit and Forth are used with Switcher, but I
don't like Edit and and it takes most of my 512K Mac's memory to hold Mach I, Edit and
Switcher. The first thing that came to my mind was MockWrite. MockWrite is a very
good text editor DA, but the versions everybody have here in Finland trash files under
HFS. (I had a lot of fun finding that out.)
I didn't know of any other DA editors when I got Mach I, so I thought writing a
small editor would not take too much time.
I still had to find a working combination in order to be able to write the editor.
The best solution I found, was to use Edit and Mach without the Switcher. In Edit, I could
use "Other" to launch Forth and in Mach, I used an FKEY to launch Edit. I modified the
menu in Edit so that I could switch programs with a command key combination. With the
cache on, it wasn't unbearably slow, but it wasn't very interactive.
I have done most of my Macintosh programming in MacForth because it was the
first good language available. Mach I is different, but learning it was easy since the
manual is good and I already knew the toolbox. I wouldn't recommend Mach I to a
beginner, but it is very good as a second language. I still miss many of the nice little
commands that MacForth has.
I extended Mach I with some MacForth words that I thought would be useful. Anew
was probably the most important. In.Heap would also have been nice, but HeapVar was
the best I could do with my knowledge of Forth. Heapvar is used to return the heap space
that is pointed to by the handle in a variable. I also added RECT, !RECT, ON and OFF. On
and Off are very simple, but they make code much more readable and speed up
programs.
Example of "HeapVar":
HeapVar A.Variable
Anew MyProgram
Variable A.Variable
100 Call NewHandle Drop A.Variable !
The editor uses the ROM TextEdit engine and is thus limited to a maximum of 64K
of text or 32767 lines. I have limited the editor to 32K of text in order to avoid
checking for the maximum amount of lines. The commented source code of TEDDY is
about 25K. This limits the amount of source code to 32K, but code segments are not
allowed to be larger than 32K.
Teddy is not the first Editor I have written. I wrote a similar program in
MacForth when I thought it would be a nice addition to my terminal program. The
MacForth version of Teddy is even simpler than MachTeddy, but the experience helped
me avoid some bugs and problems.
The program conforms closely to the Macintosh user interface guidelines. The
only nonstandard thing I can think of is the lack of an I-beam cursor. I forgot the
cursor at first, but when I thought of it, it no longer seemed worth adding. This is a
programmer's tool, after all. My MacForth Teddy has an I-Beam cursor, since it is used
by non-programmers who expect it.
The comments in the program demonstrate the things that have been less
documented in MacTutor. Scrap handling is heavily documented because the program
does it 100% according to Inside Macintosh and it has not been discussed in MacTutor.
Inside Macintosh gives very specific rules on scrap management.
The scrap is usually held in two places. The desk accessories expect it to be in the
desk scrap and every program usually has its own clipboard format. Text Edit has two
global variables to handle the clipboard. The TE-scrap must be converted to the global
scrap after a cut or paste has been made.
Teddy avoids useless scrap conversion. If a program first converts the scrap to
text and then puts it back without a change, all others' formats are lost. Consider a
situation where a user has three programs under Switcher and two of these understand
pictures. If a picture is copied and then the user switches to the other program, by first
switching to the text application, the text application should not delete the picture just
because it doesn't like pictures. Destroy the desk scrap only when you have to change it!
Teddy keeps a flag to monitor changes in the text edit scrap. If a cut or copy is
made, the flag is set and the scrap will be converted when the window is deactivated.
Desk scrap is always moved to the text edit scrap if the editor window is activated.
Menus are a very good invention, but sometimes a palette on a window is easier
and faster to use. My first experiment with palettes was with the MacForth version of
Teddy. I have used them since then on many of my programs. It would be very easy to add
keyboard equivalents to these functions, but Teddy has none. A palette is very simple to
implement: it is a collection of boxes that act like buttons. I first tried to use a
collection of buttons, but a button takes too much space.
Teddy scrolls automatically if the user tries to type outside the screen. The
selection range is used to determine if the screen should be scrolled. Cursor keys work
well, because the person who wrote Text Edit was clever enough to implement them.
Clickloop procedures are very hard to do in Forth, so I wrote the scroll routine
in assembler. The clickloop routine changes the setting of the scroll bar, but the
changes are not drawn during the scrolling because Text Edit sets the clipping rectangle
to the text edit view rectangle. If you want to be able to monitor the selection from the
scroll bar, insert a few toolbox calls to change the clipping rectangle.
The Macintosh File Manager is easy to use (once you figure out how), but
requires a large amount of initialization. I haven't figured how to use the Mach 2 file
system, so it wasn't really hard to write the routines in "pure toolbox" instead of
Forth. Note that HFS is supported simply by using the volrefnum from the sfreply and
putting it in the parmblock. The current (last used) filename and volrefnum are
remembered for later use. Loading and saving stop multitasking.