From: sje@xylos.ma30.bull.com (Steven J. Edwards)
Subject: A few more suggestions for THINK C
Reply-To: sje@xylos.ma30.bull.com
Organization: Bull HN, Worldwide Information Systems, Billerica, Mass., USA
Distribution: comp
Date: 20 Jul 92 18:06:20

Here are a few little things I would like to see in future THINK C
development.  For what it's worth:

1) Filenames in the project window should use a monospace font,
perhaps our beloved Monaco 9.  I think that tabular data should at
least allow monospace fonts, and I think Apple also shares this view
to some extent.  I note that they encourage monospace digits even in
non-monospace fonts for this reason.

2) The project window should have indicators for each entry that flag
libraries versus plain source files.  A double click on a library
entry should do something of interest, perhaps identifying some info
about the library project.

3) The transfer menu selection on the File menu does not do anything
if the selected program cannot be run due to memory limitations.  I
think that there should be two menu picks: one named "Exec" that works
like a Unix exec call, and one named "Chain" (or "Transfer") that
terminates THINK C and starts the indicated program.  This second call
would be something new and usable by those with fat programs and slim
memory.  (An example:  I have 4 MByte, but my application takes 3
MByte and a THINK C Transfer won't work; but a chain would.)

4) There should be some kind of autosegmentation option with the
project window.  Why should a deveoper fiddle with moving project
entries around?  It would be much nicer if THINK C could just generate
code segment partitioning without human intervention.  How hard is it
to count to 32 KByte?  After all, the compiler already keeps track of
this information.

5) There should be some kind of hook in THINK C project scanning that
allows a developer to specify some third party program to be
automatically invoked on C sources at specified times.  For example, a
third party semantic checker could be called each time after source
file is compiled correctly.  An indentation or pretty printer source
processor could be called after a file is changed and successfully
compiled but before it is printed.  I think that this kind of option
would go a long way in keeping down the demand for functions secondary
to compilation in THINK C itself.  If this is done cleverly enough,
THINK C could be re-invoked by some small lurker program so the whole
scheme would work on small systems.

6) The project file should keep track of potential conflicts in
compilation option values among user files and libraries.  Thus, an
unwary user would be warned if he/she chose incompatable type size
selections between a user program and a supplied library.

7) There is a lot to do with C, but it is unclear that it is wise for
one product to do it all.  I am wary of the direction of C programming
for the DOS/Windows world where some suppliers want to be all things
to all developers in a single package.  A better approach is to
segregate along commonsense boundaries so developers can get and pay
for what they need; no more and no less.  I would prefer that THINK C
have a single core product that included the integrated editor,
compiler, and linker.  The class library could be a separate part, as
could be the C++ effort.  I've personally dealt with the
multi-kilogram unitary C development packages from Borland, Microsoft,
and SCO; I really don't need another one from Symantec.  I can see the
bumpersticker now:

	"Save a tree and buy THINK C"

 [The above opinions expressed are my own; not necessarily held by others.]
      == Steven J. Edwards           Bull HN Information Systems Inc. ==
      == (508) 294-3484              300 Concord Road         MS 820A ==
      == sje@xylos.ma30.bull.com     Billerica, MA 01821          USA ==
"That Government which Governs the Least, Governs Best." -- Thomas Jefferson
Newsgroups: comp.sys.mac.programmer