• 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.



• If you're very observant, you may notice that when you ask for pico, what you really get is a program called nano. But nano is in fact just a new and improved vefrsion of pico and IT nicely created pico as an alias to nano for us so I wouldn't have to redo all these web pages, so all the web pages here that refer to pico remain valid.

•  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 it 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 actually simple enough).
  
• Unless you run emacs as an Xwindows client, it's not worth the trouble and running it that way at home would involve a bunch of extra work on your part (on campus it's fairly simple). But however you did it at home, it would look and feel differently than it does on campus and I don't want to prepare web pages walking you through all the alternatives (and their pros and cons). Our CS125 method of connecting to sun/prclab using SSH and running pico is exactly the same from both on and off campus, that's why I recommend it.)

  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 is also a Google Group taking over from the older Usenet newsgroup devoted to emacs. 

• vi was the original visual Unix editor.  It's intermediate between pico and emacs in both power and difficulty.   Good news: It, like pico but unlike emacs, works well without an X connection.  Bad news: None really, but it's pretty archaic, even in its newest incarnation as vim (vi modified), which , on sun/prclab, is what vi is actually merely an alias for. Unless you get stuck somewhere where you are going to have to do a lot of code development without a local environment and without a highspeed connection (to support X and hence either emacs or nedit) to your remote development environment, I don't see why you should bother with vi these days, frankly. (I learned vi before I learned emacs; but then, as my children remind me, I'm a living fossil from the Jurassic period of software development.)  There's a man page for vim and there are also books and Usenet FAQs available and I'm sure there are dozens of web tutorials around.
  

---

  

• nedit (stands for new editor?) is also installed on sun/prclab, although I've never used it myself. As far as I can tell, it requires an X connection or it won't run at all. (emacs, by the way, will actually run without an X connection in what might loosely be called called "text-only" mode , but you really don't want to try, trust me; that behavior of emacs is a holdover from the days of hallowed antiquity, eons past, before X windows.)

• You can also use word processing programs like Microsoft Word, Notepad, or Wordpad as editors; you just have to be careful to save the source file as an ASCII text file, not as a Word (or rtf 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. 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.