|A text editor is a program that you run to allow
you to create and edit text files by typing in characters from a keyboard.
An editor is simple-minded version of a word processor like Microsoft Word;
but it doesn't allow you to make things bold or italicized
and stuff like that. (Who cares what color your program is?) You'll use
a text editor to enter your code into source
files that can be then compiled later by a compiler. To start running
an editor and creating a new file whose name you'll pick later, you can
just enter the name of one of the editors, below, in response to a shell prompt. If, instead, you enter editorName fileName,
Unix will not only start the indicated editor but open the indicated file,
creating it (empty) for you if it doesn't already exist of course,
you'll replace editorName with one of
the editor names below. (And you'll remember to read up on the basics
of file names before choosing an unfortunately stupid fileName? Good,
I knew you would ;-)
|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.
is an industrial strength, professional tool. pico
is to emacs as a dull butter knife is to a gigawatt laser. There's a complete
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.
- 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.)
- 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
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
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
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.
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.