Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!wdh
From: wdh@well.UUCP (Bill Hofmann)
Newsgroups: comp.sys.mac.programmer
Subject: Think C 4.0 comments (LONG)
Keywords: THINK Lightspeed C
Message-ID: <13638@well.UUCP>
Date: 15 Sep 89 00:17:35 GMT
Distribution: comp
Lines: 72

Like the loyal, obedient programmer that I am, I immediately upgraded the
project (still beta) that I'm working on to THINK version 4.0.  I was
happy that there were only a few include/library incompatibilities, although
I'm not wild about the lack of smaller libraries (eg, strings, etc) - ANSI-881
is 26k: a little big to include in another segment, which I like to do to
avoid intersegment jumping whenever possible.

Thanks VERY MUCH for providing inline declarations:  this makes writing glue
for things you folks haven't gotten around to supporting MUCH MUCH easier.
In 3.0, I had to do a bunch of tedious coding to implement the 32 bit quickdraw
functions, in 4.0, I threw it out and grabbed the .h file from Apple's release
disk.  This points up another issue: even if Apple is sometimes wedged, the
more compatible THINK is with Apple's MPW C, the easier it is for us to keep
up with the latest hardware/software features.  For instance, while I *know* 
Mike had his reasons, it'd be nice if the header files were the same (both
naming and contents) for the shared features.  For the same reason, let me 
put in a pitch for maximum C++ compatibility.

Following are a few comments/complaints/kudos in more detail.  Sadly, this list
is ALMOST identical to the one I had for 3.0.  Let's hope that at least some
of them make it into 4.n+1.

-Bill Hofmann

Precompiled includes:
1.  can't cmd-click in title bar to get at .h's if they're precompiled.
    There's an easy workaround, but....
2.  precompile doesn't remember destination name a la other builds (ie,
    the sfput dialog that comes up doesn't have a default in it like
    build application does after the first time_.  Even just an algorithmic
    name, like precompiling <foo>.c producing <foo> in the sfput would be
    a time saver.
3.  precompilation maybe ought to be a little more automatic: if I change
    a .h in the precompile file, *something* should happen.  Yes, I know this
    is somewhat counter to the idea of precompiled includes, but...

Interface:
1.  Sounds for error and completion: while it IS lightspeed, it still takes
    light 8 minutes to reach the earth from the sun.  I sometimes resist the
    temptation to stare transfixed in awe at the speed of the compilation to
    do other things, like go to the kitchen or talk with a friend.  If there
    were (optional) sounds for error and completion - distinct, different
    sounds - I would be deliriously happy.
2.  More functionality in the editor.  It's fast, and I love the balance
    command, but here are some other suggestions:
a. More arrow key functionality: look at the way MPW uses the keys: yes, 
    some of us would rather type Cmd-Sh-Up to get to top of file than drag the 
    thumb, or Cmd-Up to go up and down screen-by-screen.  Also a fave of mine
    is Cmd-Left to go to start of line, Cmd-Right for end of line.
    Thanks for finally fixing the left-right arrow keys....
b. This is a C development environment, after all: how about "Comment out
    Selection" (either with #ifdefs or a /* on each line, */ at end), how about 
    a command to add a comment to the end of the line: it would move to end, 
    tab, put open and close comments and position you between them.  One thing
    I tend to do a lot is use the balance command to move my way to the top or
    bottom of a function.  How about an arrow key combination to do that? (eg,
    option-up=top of function, option-left=out one level of delimiters towards
    the top of file).
c. more functionality to balance: balance single quotes, double quotes.
    Maybe a modifier to not include the balance characters (a la MPW)
d. perhaps some way to exclude comments from searches?
e. I happen to like the MPW regular expression set.
Does it show that I used to use EMACS?  I don't think that it's a bad thing for
a program editor to have gobs of key equivalents to do things useful to the 
language in question.

3. Of course, I would love a set of 100% compatible Rez and Derez tools so I
    didn't have to run MPW all the time.  RezTools doesn't cut it, because I
    have multiple .r files.  Face it guys, RMaker is a stone-age product.

OK, most of these are minor.  It's a great product, and these would make it
greater.