Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!kithrup!sef
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.lang.c
Subject: Re: HELP, WE'RE DROWNING!!
Message-ID: <1991Jun25.073955.29138@kithrup.COM>
Date: 25 Jun 91 07:39:55 GMT
References: <1991Jun22.154152.29478@thunder.mcrcim.mcgill.edu> <1991Jun24.163819.3125@email.tuwien.ac.at>
Organization: Kithrup Enterprises, Ltd.
Lines: 30

In article <1991Jun24.163819.3125@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes:
>When I have have to work on an ASCII-Terminal, I see many
>advantages. E.g. source code and compiler error messages are
>simultaneously visible. If I have an X-terminal, still one advantage
>remains. The debugger. Turbo-Debugger is the best debugger I have ever
>seen. Dbx isn't more powerful, and not nearly as comfortable.

I would suggest you try emacs, gcc, and gdb.  compile-mode in emacs will let
you go to the line of the error; gdb-mode in emacs points out the line
currently under inspection.  More, emacs can be reprogrammed relatively
easily to handle *your* particular preferences.  Also, emacs can work with
any C compiler (well, almost any... all that I know of).

>Yes, I miss vi. But using the integrated environment is faster than using 
>vi, make and a debugger.

Again, try emacs and gdb.  I think you will be pleasantly surprised.

>>- "text" vs "binary" stupidity in the I/O libraries

This is mandated by non-unix os's which think that file's should not be
streams of characters; also, other OS's (such as MS-DOS, although that's not
the only one) do not have '\n' as the sole End-Of-Line sequence.  It isn't
generally a problem.

-- 
Sean Eric Fagan  | "What *does* that 33 do?  I have no idea."
sef@kithrup.COM  |           -- Chris Torek
-----------------+              (torek@ee.lbl.gov)
Any opinions expressed are my own, and generally unpopular with others.