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", "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:

• set autoindent will cause every line to automatically be indented the same amount as the previous one. You can use control-T and control-D to change the indentation level.
• set shiftwidth=4 will change the amount of indentation (from control-T and control-D) to be 4 spaces.
• Matt Brubeck has provided the following lines, which apparently help in working with my personal indentation style. I don't know what most of them do, so you'll have to trust him:

  set cino=>4{4(4	sw=4          " Kuenning-style indentation
  set comments=sr:/*,mb:*,el:*/ " C-style comment formatting
  
  " Enable these formatting options for .cc and .hh files:
  au BufEnter *.cc,*.hh,*.icc set cindent tw=78 fo=tcqro
  

• For vim, Dan Lowd has provided the following options that may be helpful:

  set et			" Expand tabs
  set ts=4 sw=4		" Short tabstops
  set ai			" Autoindenting
  
  " Use cindent on all source code files
  autocmd BufRead *.c,*.cpp,*.h,*.cc,*.hh,*.icc,*.java set cindent
  

  Dan also writes: "The options for cindent can be set to format just about any reasonable coding style. From inside vim, :help cindent for more info. :help cinoptions and :help cinoptions-values give detail regarding how to set these. It's not painful."

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

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.)

Should I document topic x in the README file?

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.

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

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

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

    tr -d \\015 < file1 > file2

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.

How can I get make to show me the errors in all my files?

Run make with the -k ("keep going") switch. It will run as many compile commands as it can before it gives up. If you get more than a screen of errors, you may wish to redirect the output into a log file. In csh and tcsh, use "make -k >& make.log". In ksh and bash, use "make -k > make.log 2>&1".

What about this handy emacs compilation mode I've heard about?

Inside emacs, run M-x compile RET RET. The editor will open up a second window and run make inside it. When the compile finishes, type C-x ` (that's a reverse quote, also known as back quote or backtick, which is usually in the upper-left corner of your keyboard). Emacs will automatically jump to the point of the first error message. Fix your code, and type C-x ` again to go to the next error. Keep fixing errors as long as you like, and then save your files and type M-x compile again to see how much better things are.

© 2004, Geoff Kuenning

This page is maintained by Geoff Kuenning.