wdh@well.UUCP (Bill Hofmann) (09/15/89)
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.nick@lfcs.ed.ac.uk (Nick Rothwell) (09/15/89)
In article <13638@well.UUCP>, wdh@well (Bill Hofmann) writes: >Interface: >1. Sounds for error and completion: while it IS lightspeed, it still takes > light 8 minutes to reach the earth from the sun. A few weeks ago, I had this wonderful idea - use the RAM cache! Never thought of it before, since hardly anything else seems to like the RAM cache that much, but TC runs like a dream - sometimes, NO disk access at all to compile a module, even for the #includes. >2. More functionality in the editor. It's fast, and I love the balance > command, but here are some other suggestions: One thing I'll scream for in the editor - the ability to have two views on one file, perhaps as a window split or something. I'm always having to look at a struct declaration at the top of a file and use it lower down. I'm too used to EMACS, I suppose. >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. I use ResTools a lot, with several .r files. I just have a top-level .r file which pulls in the .rsrc files from the lower ones. So, you have to issue more commands, but it seems fine. Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Fais que ton reve soit plus long que la nuit.