• pico

pico is a simple, easy-to-learn, self-documenting, text editor designed at the University of Washington for use by undergraduates in introductory programming courses.  There's a man page for it, and it has a good set of internal help pages.  Unless you're in the mood for a real challenge, I'd look no farther than pico.

•  emacs is an industrial strength, professional tool.  Pico is to emacs as a dull butter knife is to a gigawatt laser. There's a complete online reference manual for emacs as well as a short Unix man page, but one of the features that makes emacs the professional's editor of choice is that it has a literally stupendous set of  internal documentation, including a built-in tutorial.  Enter emacs in response to a shell prompt and then once emacs starts up,  type ^h (that's a control-h) to start the emacs "help" process.   (What pico and much other Unix documentation [not all] displays or prints as ^h, the emacs documentation displays as C-h; welcome to the joys of the computer profession where consistency is not our most important product.)   To quit emacs, type ^x ^c — or in emacs terms, C-x C-c.

Reasons not to use emacs:

• Vast overkill for introductory programming assignments
• Harder to learn than pico (although the basics are certainly simple enough).
  

  Reasons to use emacs:  

• If you're going to be a  professional programmer, you'll probably want to pick it up eventually anyway.  Do it now and be the first on your block to be an emacs guru.
    
  
• Nearly universal availability; freeware versions are available for almost any operating system you've ever heard of (and many you probably haven't).  Pico is a teaching tool; you'll probably never see it again once you leave ERAU.
    
  
• emacs is what is known as a context-sensitive or language driven editor.  That means it has lots (I mean really lots and lots) of editing features and functionality specifically devoted to the support of computer programming, like, for four trivial examples out of hundreds (thousands?):
  

• Controls to allow you to highlight or quickly find the corresponding closing or opening match to an opening or closing parenthesis, bracket, or brace.
  
  
• Convenient support for abbreviations, so that you can type just the first few characters of 
  long_complicated_variable_names that make your program easier to read and will be required for professionally_documented_code (and will make your kindly and fatherly instructor not scowl at the sheer incomprehensibility of a program of yours with stupidly cryptic variable names like v0).
  
  
• Automatic formatting of long comments that spread across multiple lines but are required in professional practice and also help explain to your instructor what you were even trying to do even though you failed miserably and never actually got it to work.  Don't come make excuses to me about it; put it in your program's comments; I may be so impressed I'll give you a point or two of partial credit anyway.
  
  
• Automatic, language dependent formatting.  It knows how to indent and do other things to portray  the correct relationships among a series of related or nested statements.  This "pretty-printing" makes it much easier to read and understand source code and is a required professional practice that is, or should be, required for students as well.
  

Although I very much admire (and use) the tremendous built in help features of emacs, I still recommend that when you are first starting out you use a web tutorial or get a good book (I used O'Reilly press's Learning GNU Emacs by Cameron, Rosenblatt, and Raymond).  Hard core old timers will tell you to skip the book or web tutorial and learn emacs from within emacs.  (They'll also tell you that real programmers don't use high level languages and never bother with documentation.)  There are also several Usenet newsgroups devoted to emacs. 

Emacs, like pico and vi,  is installed on sun and can be run there via an SSH connection; but, unlike for the other editors, you may well need to remap the keyboard binding of your "Backspace" key for your SSH client. You can also download and install emacs on your own PC so you don't need to tie up your home telephone line with SSH to edit your program files here on campus.  (It's a big download, by the way, if you're using a phone modem [or even if you're not]; but just set it up some night and go to sleep, it will finish by the next morning.)   Another nice thing about using a local copy of emacs is that the mouse can be used for the usual mousy sorts of things.  Over SSH, you can't use the mouse — the SSH protocol doesn't pass mouse data.  Emacs was originally designed for use in a pure keyboard environment without a mouse, but the modern versions all accept mouse stuff too and it is convenient.  (Although working Xservers, which do handle mouse commands, are  installed on the King lab Windows machines, you certainly don't want to be running an X session from home over a dial-up connection. If you have a broadband connection, you can tunnel X through the campus firewall from off campus using SSH.)  

---

• vi was the original visual Unix editor.  It's intermediate between pico and emacs in both power and difficulty.   vi is even more available than emacs since it's actually bundled in to every Unix distribution (that's not true of emacs, which has to be installed separately),  and there are vi programs available for most non-Unix platforms (such as Microsoft Windows) for which an emacs is available.  In fact, emacs itself includes a vi emulation mode, since vi used to be the professional's Unix tool of choice until emacs came along.  (I learned vi before I learned emacs; but then, as my children remind me, I'm a living fossil.)  There's a man page for vi and there are also books and usenet FAQs available and I'm sure there are dozens of web tutorials around.

• You can also use word processing programs like Microsoft Word or WordPerfect as editors; you just have to be careful to save the source file as an ASCII text file, not as a Word (or WordPerfect or whatever) document.  A modern word processor combines editing functions with formatting functions (making things bold, or littler, or italicized, etc) and WYSIWYG displays.  The file that's output includes (normally) invisible data describing the formatting to be applied to the visible text.  A compiler would be hopelessly confused by such a formatted file.  (Save a Microsoft Word document in rich text format [it will have an rtf extension] and then open it with Notepad to see all the "extra" crap I'm talking about.) Fortunately, most word processors allow you to  save just your text and discard any formatting instructions.  In Microsoft Word, for example, ASCII or text-only is one of the "Save as" options from the file menu.

• You may also need to understand and change the default way your word processor inserts carriage returns and line feeds and stuff when you hit the "enter" key (and even when you don't — the Intermediate Unix tips you can read later discuss the nature of the carriage return problem).  Compilers sometimes attach different meaning to carriage returns and line feeds than word processors do.  Try creating a short source program with your favorite word processor; save the unformatted text output and look at it with more or cat.  If it looks ok, it probably is.  Then try a quick compile.  If there are invisible problems with the file, the compiler will certainly let you know (and gently, of course, the way Unix always does ;-)
     
  

Why bother?  Good question.  I wouldn't, really, but students keep asking me about this, so I figured I'd mention it here. Yes, it's possible; no, I don't see much point to it. In fact, I think it's counter-productive, since it encourages you to violate "build-a-little-test-a-little" by entering too much of long complex programs off-line, without ever trying to compile. Then when you do upload and compile, you'll probably get a gazillion error messages. Very discouraging; better to edit small chunks and compile them frequently; even if you have to tie up your phone line more to do it.