• MobaXterm includes an easy to use editor named MobaTextEditor; it's my recommendation for undergraduate programming, particularly for lower division courses. Note: MobaXterm is a Windows program; if you're a Mac user, see nano, below.

•  emacs is an industrial strength, professional tool.  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 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 MobaTextEditor (although the basics are actually simple enough).
  
• Unless you run emacs as an Xwindows client, it's not worth the trouble. On campus, running emacs on prclab as a client to an Xserver on your local machine is fine (I do it often); but from off campus the connection is so slow as to be completely unusable, take my word for 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). 
    
• 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 MobaTextEditor and emacs in both power and difficulty.   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 high enough bandwidth connection (to support X and hence emacs) 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.

• Nano is a user-friendly, easy to use editor installed on prclab1, where it is accessible to both Mac and Windows users from the prclab1 shell. It was designed specifically for use by undergraduates in early programing courses. MobaTextEditor is better, but it's a Windows program that runs locally on a Windows machine and hence is not available for Mac users. nano runs remotely (on prclab1) and is therefore usable by a Mac user connected to prclab1 (via ssh, the only conection prclab1 accepts). Here's a quick overview of nano and how to use it from a Mac.

• Notepad++    Notepad++ is for programming on Windows machines; to use it for programs for prclab would require its user to manually move their file over to prclab1 to compile (and debug), which would be a giant and unnecessary pain in the ass. I can't think of any offsetting advantage to that, so don't. Note: MobaTextEditor does this (stores a local copy) but it does so more or less transparently for the user.