You've been running programs in immediate (interactive) mode. After any changes, to see the changed output, you must arrange for all lines to be run again in order. Real programs consist of many lines and possibly many files. These are saved to be run again later. Any changes, bug fixes, improvements can be made, while leaving the bulk of the file unchanged.
To write these files you need an editor. An editor displays on the screen all the characters that will be saved to the file. There are no hidden and undisplayed characters for formatting and printing that a part and parcel of word processors. An editor shows you exactly what will be saved, no more, no less. The editor saves the file with the name you give it and doesn't try to be smart and give your file an extension that it thinks is better.
An editor must do the following
- enter and delete text
- move/copy lines or blocks of text
- search for and replace (translate) text
navigating
- tell you the line number and column at the cursor.
- move to a given line number or search string. when you get there, display that line in the middle of the screen.
It's not a lot to ask.
 | Note |
|---|---|
| If you've been using an editor to do your binary math examples above (rather than pencil and paper) and you're happy with it, then you can skip to saving_files. | |
unix/cygwin:
The most commonly used editors are vi and emacs: unfortunately the human interface for both is execrable. I miss MultiEdit, the editor from my DOS days. Some people use pico, but the license is not GPL compatible, so a pico-like editor nano has be written. Both nano and pico are also available for windows.
vi
This is the simple editor, with a minimum number of commands required to edit. It's simplicity was required in the early days of networked computers when the small bandwidth available only allowed simple tools to be used to administer remote machines.
There are many "improvements" to vi, all of which are directed to destroying the best feature of vi - its simplicity, while ignoring the real problem, the human interface. The "improved" versions of vi color each word differently (anyone for yellow letters on white background, how about dark blue on grey) and attempts to render html as it would be displayed in a browser, not as you'd want an editor do display it (so you can edit it).
vi was written for keyboads which didn't have enough keys to issue commands and to edit at the same time. This is no longer true for modern keyboards, there are plenty of keys now, but in vi you have to remember whether you're in edit of command mode. As well vi gratuitously beeps at you all the time. The only purpose of this is to keep others in the house awake while you're coding at 3am.
The documentation for vi is impenetrable and doesn't tell you how to turn off the improvements, only how to make them more complex.
To counter the "improvements" to vi, I use a version from about 1990, before the era of "improvements".
emacs
This is the all singing/all dancing editor which does everything that a computer can do. It's likely that someone has already mathematically proven that emacs will do anything that any computer will ever be able to do. If ever your computer can make coffee, you'll first be able to do it from emacs. Unfortunately my early apprenticeship in emacs was stopped dead when I had to use a DEC windows machine for a couple of years. One of the vital keys for emacs, C-s, was a signal to the VAX to turn off the keyboard (neat feature huh?). A couple of years following that of administering machines over a phone line (probably 4800bd) and I was a vi convert.
Networks and computers are a lot faster now, and it's reasonable to use emacs over a network. However most commands require two lots of keystrokes, when one would do.
There have been no attempts to "improve" emacs. Everyone who uses it, likes it just as it is.
nano
From the NCSA discussion mailing list (and other places) comes these suggestions for windows/Mac editors other than vi and emacs
Mac:
- textedit
- textwrangler (http://www.barebones.com/products/textwrangler/)
- textmate (http://macromates.com/)
- subethaedit (http://www.codingmonkeys.de/subethaedit/) (shareware)
windows:
IDLE which comes with python. (IDLE seems to be a regular programming editor and will save files with any extension.) IDLE gives you a standard immediate mode python prompt (but without history recall, i.e. the up-arrow doesn't recall the last command - if you want history, then you need to use the python interpreter). You can do a file save from here: it will save the sign-on info and messing around you do. This is not what you want. Instead do file-new window, when you'll get a regular editing window.
Warning IDLE (at least initially) wants to save your program in a directory that it has no business saving files to. See the note for notepad++. Getting Started with Python in IDLE (http://www.ai.uga.edu/mc/idle/index.html)
- notepad, comes with windows
notepad++ (http://notepad-plus.sourceforge.net/uk/site.htm) (the download link is hard to see, it's orange on white).
Warning notepad++ by default wants to save your files in c:\Program Files\Notepad++. do not do this. The Program Files directory and its subdirectories are for well tested and safe programs to be used by everyone on the computer. These directories are not for your development files, which must be kept where they can't do any damage, like in a subdirectory of \Documents and Settings\UserName or \My Documents. - crimson edit (http://www.crimsoneditor.com/). I tried this when I was forced to use windows and didn't like it, but I can't remember why - I think it was too complicated to use.
- editpadlite (http://download.jgsoft.com/editpad/SetupEditPadLite.exe) - the download link is hard to find - it's at the bottom of the page, below the exhortations to buy the professional version. The installed version wants to talk to you a lot. You'll have to find out how to turn it off if you want to do any work. It's free for non-commercial use. It supports unlimited file size and multiple files open at the same time, which notepad does not. (I don't have enough brains to handle two files open at a time.)
- windows extensions for Python (http://sourceforge.net/projects/pywin32/, also possibly known as win32all) which I know nothing about, but which is supposed to have an IDE.
- pico available for windows and unix. (have not tried it, apparently you need to run it with pico -w to stop it linewrapping - pico was originally used to compose e-mail).
nano
nano download, look in the NT directory.
When I had to code on windows (worst 3 days of my life), I installed cygwin and could pretend I was working on a unix machine. This is a reasonable approach if you already know the unix tools.
For this class pick any editor you like. Be prepared to try a few editors before finding one you like. Everyone is different and everyone likes a different editor. I like mine really simple. It seems that others like theirs complicated.
If you find yourself programming on a long term basis in a unix environment, and you expect you'll be sitting in front of a machine that someone else has setup (e.g. at work), that you should learn one of vi or emacs. It's quite disappointing to realise that the program you spend most of your time with, the editor, has such a bad interface and that no-one has designed an editor for unix like the much nicer ones available on the much dispised Microsoft platforms.
pick a name for your python files directory e.g. class_files.
- unix/cygwin: in /home/username/class_files/
- windows: in \Documents and Settings\UserName\class_files\ or \My Documents\class_files\ (two names for the same place).
Your files need to be in a place where no-one else is likely to run them accidentally. Until your files are well tested and of general use, they should be kept in your directories.