Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!ux1.cso.uiuc.edu!iuvax!copper!huntley
From: huntley@copper.ucs.indiana.edu (Haydn Huntley)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C Suggestions
Message-ID: <61078@iuvax.cs.indiana.edu>
Date: 29 Sep 90 19:55:44 GMT
References: <695@sun13.scri.fsu.edu> <10490@hubcap.clemson.edu> <587@ohs.UUCP> <1990Sep24.180828.18625@cs.cmu.edu> <1990Sep28.121554.18758@maths.tcd.ie>
Sender: news@iuvax.cs.indiana.edu
Organization: Indiana University, Bloomington IN.
Lines: 89

I've been in love with Think C for three years, but there are a few
things I'd love even more if they were improved...

1) 	Have the arrow keys be customizable, or be like MacWrite's -- 
	with option, shift, control, and command as modifiers to make
	the cursor move by characters, words, line, page, or the
	beginning or end.

2)	Have PageUp, PageDn, DeleteRight, and shift-delete work.

3)	It would be nice to be able to search and replace backward,
	and wrap-around is sometimes useful, too. (via check boxes)

4)	Add a command for assembler output, like the command-K
	function for compile.  That way we can see what kind of code
	Think C is generating, so that we can decide if we need to
	optimize it, and so that we have something to begin optimizing
	with.
	
5)	Wildcard filename expansion in ccommand() would be nice.
	Also, if it would accept pathnames in Unix style (with slashes
	as the seperator, that might also be useful.

6)	Show line numbers in the editor.  There are many programming
	tools one can port from Unix and MS-DOS, and when they detect
	an error, they tell what line number it occured on.  In Unix
	or DOS it's easy and convenient to use that information, but
	in Think C, it isn't very helpful, just because the editor 
	doesn't tell what line the cursor is on.
	One candidate location for displaying the line number might
	be to the left side of the horizontal scrollbar, where some
	applications put the page number.

7)	It would be nice if the compiler would give warnings -- just like
	gcc, Turbo C and Microsoft C do.  The warning messages could
	be displayed in another window, like the linker error listing
	does.  Additionally, it would be nice to be able to turn on
	and off all of the warnings as a group, as well as
	individually, like one can in Turbo C or gcc.  Some of the
	warning messages might be things like pointer-integer arithmetic
	combination, unreferenced variables, dead code,
	unparenthesized assignments within the test of an if, missing
	prototype, etc, etc.  I really like the way that Turbo C can
	be configured to warn about suspicious code constructs,
	especially type and argument mistakes.

8)	It would be convenient if the project would save the debugger's
	settings whenever possible.  For example, if a function still 
	had the same number of lines, its breakpoints would be saved, 
	and if it still had the displayed variables, then those would 
	also be saved and restored.

9)	It would be really nice if Think C could really check to make sure
	that the correct type of arguments were being passed to
	library and toolbox functions.  Right now it only checks the
	size, and that isn't very helpful, because Points, longs, and
	the pointers to different types are all 4 bytes long!  Having
	the MacHeaders file sure speeds things up, but catching 
	mistakes at compile time saves alot of debugging!

10)	For folks like me who like having their function calls type
	checked, it would be convenient if Think C had an option to 
	generate header files.  Microsoft C can do it, though it takes
	almost as much time as compiling the file!

11)	I'd appreciate if it were possible to fix the bug in the
	console routines, where once you do some output, they trap 
	*all* incoming keystrokes, even the command keys.
	This is not in accord the documentation on the bottom of 
	page 166 in the Standard Libraries Reference.

12)	The qsort() function could be much faster, and the version
	that I worked on is smaller, too!  You're welcome to use it.

Whew!  I know that's a long list, not because Think C isn't my
favorite Mac programming tool, but because I'm a bit of a
perfectionist, and thus difficult to please.  I love fast,
intelligent, esthetically pleasing software, and when a friend
introduced me to Think C 2.0, I was blown away -- I'd never dreamed
that I would get to *work* in the type environment I was trying to
create for users!

Thanks for making such a wonderful tool, and thanks for asking us for
suggestions to make it even more wonderful!

--Haydn
;;  *****************************************************
;;  *  Haydn Huntley    huntley@copper.ucs.indiana.edu  *
;;  *****************************************************