Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!sunic!kth.se!draken!d88-jwa From: d88-jwa@nada.kth.se (Jon Watte) Newsgroups: comp.sys.mac.programmer Subject: Re: Wishlist for THINK _C_ (4.1 ? 5.0 ?) Message-ID: <3200@draken.nada.kth.se> Date: 24 Mar 90 13:45:24 GMT References: <3192@draken.nada.kth.se> <2274@cbnewsk.ATT.COM> Reply-To: d88-jwa@nada.kth.se (Jon W{tte) Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 70 In article <2274@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: >From article <3192@draken.nada.kth.se>, by d88-jwa@nada.kth.se (Jon W{tte): >> 1. Compiler errors are accumulated in a separate window and may be >in addition to the one-class of errors at present. But probably requires >Kahl and co. to rearchitect the compiler, so I guess I could live without It would be _more_ than nice. Ever run gcc and gdb under gnu emacs ? Not that I'm a gnu fan, but they sure make some neat things... >> 2. Some support for several different project/description files, >> and maybe cross-dependancy as well. >I don't know what this means. You can include one project into another Yes, but to close one project and open another and switch back & forth isn't my view of user-friendliness (For example; NetHack has two support applications that needs to be run when you touch certain files) >> 3. Some means of reading/saving the project layout into a text >> file (maybe read in a make(1) file and convert to a projcet ? 8-) >I can't get excited about this one. When I begin a port, I have to >pound the "Add..." dialog a bunch. So what? Well. In the case of NetHack (again :-) it would save us the trouble of distributing a hqx-ed project file... Okay, it would be neat, but not essential. >> 4. Grep in files with name matching (not necessary in the >> project) >Same comment: yawn. So do you have a grep that can scan through all files in a directiry ? I'd be very interested in it, in that case. (I _often_ use egrep "" f*.c or similar on unix boxes) >> 6. A means of setting various #define's globally. >I'd like this one too. But then, most of my projects already have >a catch-all header for inclusion in every file, so... A hitch: pre-compiled headers mustn't rely on these #defines... >> 7. Some way to set breakpoints in a source file other than the >> current, without using Debugger() (Or have I overlooked something ?) >I don't understand this one. I have Debugger() and DebugStr, and once a Well, maybe I want conditional breakpoints. I was mailed how to do this, I just hadn't seen it in the manual (Top of page 141) But then, I always "Set Aside" everything but the debugger and the project... >To the above, let me add one more: permit me to do builds in background. Yes ! Yes ! Yes ! Now, this is something I've wanted for years ! (Maybe as a check box under compilator flags, to avoid as much overhead as possible ?) Wishing for a white Christmas, h+ -- --- Stay alert ! - Trust no one ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request