Troubleshooting

If no completions show up or emacs reports errors, you can check the *ycmd-server* buffer for errors. See the next bullet point for how to handle “OS Error: No such file or directory”

Launching emacs from an OS menu might result in a different environment so that ycmd does not find ninja. In that case, you can use a package like exec-path from shell and add the following to your init.el:

ff-get-other-file

There's a builtin function called ff-get-other-file which will get the “other file” based on file extension. I have this bound to C-o in c-mode ((local-set-key "\C-o" 'ff-get-other-file)). While “other file” is per-mode defined, in c-like languages it means jumping between the header and the source file. So I switch back and forth between the header and the source with C-o. If we had separate include/ and src/ directories, this would be a pain to setup, but this might just work out of the box for you. See the documentation for the variable cc-other-file-alist for more information.

One drawback of ff-get-other-file is that it will always switch to a matching buffer, even if the other file is in a different directory, so if you have A.cc,A.h,A.cc(2) then ff-get-other-file will switch to A.h from A.cc(2) rather than load A.h(2) from the appropriate directory. If you prefer something (C specific) that always finds, try this:

find-things-fast

erg wrote a suite of tools that do common operations from the root of your repository, called Find Things Fast. It contains ido completion over git ls-files (or the svn find equivalent) and grepsource that only git greps files with extensions we care about (or the equivalent the find | xargs grep statement in non-git repos.)

vc-mode and find-file performance

When you first open a file under git control, vc mode kicks in and does a high level stat of your git repo. For huge repos, especially WebKit and Chromium, this makes opening a file take literally seconds. This snippet disables VC git for chrome directories: