Written by Julie Zelenski and Chris Gregg, with modifications by Nick Troccoli

There are a variety of text editors available on myth: emacs, vim, gedit, nano, pico, and more. Each has their intended audience and makes tradeoffs between ease of learning, usability, customization, extensibility, and so on. Zealots might insist that "all real programmers use my-favorite-editor-here" but there is no "best" choice. nano, for instance, is another editor on the myth machines that is very simple to use, but does not have many advanced functions. Our staff is split between users of vim and users of emacs, so that is where our particular expertise is concentrated, and those are the two editors we recommend (see our emacs and vim guides), but tutorials and features for other editors are only a Google search away. Don't obsess over which editor to use, choose one and get practicing so that you can be happy and productive using it.

Note: In Summer 2021, Andrew will use vim in live lectures, but the pre-recorded lecture videos (by Nick) will use emacs. You are certainly welcome to use either. If you are unsure, we would recommend emacs as its learning curve is initially not as steep. But the course staff will do its best to support you with either.

I've heard that some terminal editors offer a GUI mode. Is that true?

Some programs, like emacs, do have a mode more like the word processing programs you've used with windows, menus, buttons, mouse input, and so on. To use this, however, you must set up a terminal program with windowing capability. While we don't officially support this in CS107, you can feel free to look up online how to do this. A terminal editor, however, which is the text-based version of something like emacs, is typically very low bandwidth (advantageous if your network connection isn't so speedy).

Can I use a local editor to edit remote files?

You may have a preferred text editor (XCode, TextPad, Sublime, Atom, Notepad, etc.) on your local machine and you'd like use it to also edit myth files. Although there are ways to make this work, it involves hassles and risks that shouldn't be taken lightly. We also don't recommend relying on it as your first and only plan. Everyone should invest in learning a Unix-based editor and practice until reasonably comfortable. These skills will serve you well now and in the future, as a local editor setup won't always be available or appropriate. It's true that when it's working, using a local editor is quite convenient, but there are many things that can go wrong, and the potential instability, system hangs, and data loss can be mildly irritating to downright devastating. You must make your own informed decision about whether it's right for you and if so, pursue at your own (considerable) risk. The course staff will not answer questions about these tools, nor will we configure or debug your installation. You should practice good revision control and backing up as a preventive measure against catastrophic events. We've seen students lose an entire file in the blink of an eye!

If you do decide to use this approach, however, you'll need a way to get files from AFS (the filesystem myth displays) to your local computer. Below are some options. Each has certain installation hassle, workflow disruptions, and exposure to risk.

1. You can access your AFS files via web browser at afs.stanford.edu and copy files between AFS and your local computer . One (painful!) workflow would be to use a web browser to download a file from AFS to your computer, edit using your local editor, and then upload the saved file back to AFS.

2. Alternatively, using a file-transfer program (e.g. scp, sftp, SecureFX, Fetch) to copy the file between AFS and your computer, which is a mild improvement over the clunky web interface.

   Both 1 and 2 require a manual copy after every edit which introduces a lot of friction in your development process, not to mention the risk of copying the files in the wrong direction and losing work.

3. Some editors (Sublime, Coda, NotePad++, and others) build in SFTP capability, where a local save is automatically translated into a transfer operation to AFS. When working, this is pretty seamless and convenient, but on a glitchy network it can result in missed updates, weird synchronization issues, and dangerous data loss.

4. An even-more-invasive approach is to install OpenAFS (available from Stanford IT Services), mount the entire AFS filesystem, and directly access files. Your mileage may vary using this approach, as it has been known to suffer from kernel panics, system hangs, and lost edits.

The simple and safe approach is to choose a unix editor and stick with it. There is a bit of a learning curve initially, but once at a comfortable place, you may find you are working even more productively than previously and won't miss your local editor after all!