🚀 go-pugleaf

In article <137@geac.UUCP> len@geac.UUCP (Leonard Vanek) writes:
>In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>>
>>User preferences vary, and I'm sure my opinion on them isn't shared
>>by everyone.  My point, however, is that it is not sufficient to choose
>>between a mouse interface and a dialog interface solely upon the type
>>of output device.  I would prefer a command-line interface even on a
>>bitmapped screen, and I suspect many other "power users" of UNIX would
>>also.
>>
>The above point leads me to wonder about the use of the two
>editors that come with the Macintosh version of the Aztec C
>compiler.
>
>How many users of Aztec C (or any other Mac compiler that
>offers the choice) use the vi-like Z editor or the
>mouse-based Edit? 
>

I use the Z editor -- in fact, it's one of the reasons I bought
Aztec C.  Although I'm not entirely thrilled with vi, I'm used
to it and can live with it.  I haven't used Edit much at all but
I do use MacWrite regularly, mainly for correspondence but also
for memos.

Switching between mouse-based editing and a 'traditional' screen
editor has made me rather schizo.  It never fails that I'm in Z,
want to delete a large block of text, and reach for the mouse to
select the text.  Conversely, while in MacWrite I often enter
an (pseudo) ESC in an attempt to terminate text entry or try to
move backwards using 'b' or '-'.

I do like having the choice of environments, but I would like an
'integrated' (i.e., both pointer and command) environment even
better.  The examples I cited above illustrate the respective
strengths of each interface and suggest ways in which each could
be exploited to compensate for the weaknesses of the other.

I also like having the Aztec shell available on the Mac.  The
simultaneous menu and command-line interface is a simple example
of an integrated environment which is handy to use, especially
the compilation menu (does away with the need for compile/asm/link
scripts for simple programs).  The main problem with the Aztec shell
is that it's not really UNIX -- it can be quite frustrating not
being able to form pipelines, spin off background processes, etc.
Considering that it is a simple Bourne shell plus a number of
UNIX commands in a single program, however, it's pretty good.

Dave Bursik/..cbosgd!db