CS70, Fall 2000

Frequently Asked Homework Questions

  • How can I get emacs to cooperate?
  • How can I get vi/vim to cooperate?
  • Why do I get the message "Make: missing separator?
  • Should I document topic x in the README file?
  • What can I do about CR/newline differences when I upload files?
  • How can I get emacs to cooperate?

    The default C++ editing mode for emacs does not encourage very good style. Fortunately, there is lots of opportunity for customization. One of the best ways to customize is to choose a different named style, or to create one of your own (the latter is very difficult).

    To choose a different named style as the default, add the following line to the end of your .emacs file:

    (setq c-default-style "stroustrup")
    

    Then exit emacs and reenter it.

    The string "stroustrup" can be replaced by any of "bsd", "cc-mode", "ellemtel", "gnu", "java", "k&r", "linux", "python", "stroustrup", "user", or "whitesmith", each of which produces somewhat different results. I haven't experimented a lot, but I suspect that "bsd", "k&r", or "stroustrup" would produce pretty good results.

    You can also change the so-called "basic indentation offset". The default value is chosen by the style; for example, the "gnu" style uses a value of 2, which means that most if statement bodies are indented 2 spaces more deeply than the if itself. To change the basic offset to a more reasonable value, add the following magic to the end of your .emacs file:

    (add-hook 'c++-mode-hook (lambda nil (setq c-basic-offset 4)))
    

    You can replace the "4" with any number you choose.

    Finally, some of us hate the emacs C++ mode with a passion and would rather just have the editor do what we ask it to. The following line, added to your .emacs file instead of the above ones, will cause C++ files to be edited in text mode, but without automatic paragraph filling:

    (add-hook 'c++-mode-hook (lambda nil (progn (text-mode) (auto-fill-mode 0)))
    

    For your convenience, all three of these lines can be found on Turing in the file ~geoff/Dot-emacs.c++-mode.

    How can I get vi/vim to cooperate?

    Like emacs, vi contains some useful features for editing code, with defaults you might want to change. Here are some things that you can add to your .exrc or .vimrc file to change vi's behavior:

    Missing separators in make

    Q: Why do I get the message "Make: missing separator"?

    A: The prototype commands in your makefile do not begin with an ASCII tab (control-I) character. Make is very particular about this. You can verify this by placing your cursor at the beginning of a line, and then moving it forward one character (control-F in emacs). If you have a tab, the cursor will jump forward by several character positions. If you have a blank, it will move forward only one character.

    If you use emacs to edit your makefiles, it should enter a special "makefile" mode so that the tab is automatically inserted when you type the TAB key. Avoid using the space key to align things; use TAB instead. (This is a good general rule even when you're not working on a Makefile.)

    What goes in the README file

    Q: Should I document topic x in the README file?

    A: If you have to ask, put it in. The graders do not normally deduct points for having too much documentation. In contrast, you can easily lose points for not having enough.

    CR/newline differences

    Q: What can I do about CR/newline differences when I upload files?

    A: Different systems use different representations for line separators. Unix uses newline (also known as LF, or control-J). Macs use CR (also known as control-M). DOS and Windows use CR followed by a newline. When you upload a file using ftp (or sometimes using other methods), these notations are preserved. In either case you can cure the problem on Turing using the tr (translate) command. This command reads from its standard input, writes to standard output, and performs simple character changes in the process.

    For files uploaded from a Mac, translate CR into newline with:

        tr \\015 \\012 < file1 > file2
    
    where file1 is the file from the Mac and file2 is a scratch file that will receive the translated information.

    For files uploaded from a DOS/Windows system, use:

        tr -d \\015 < file1 > file2
    
    with the same file naming conventions.

    In either case, if you aren't 100% sure whether your file is already in Unix format, running the command will not hurt anything. However, if you run the Mac version of the command on a DOS/Windows file, you will wind up with double-spaced lines, which is probably not what you want.