Updated Feb. 10, 2018
Updated Oct. 14, 2019
Just over a year ago I wrote a post about using Emacs is a C++ IDE. Over the past year many small improvements have led me to an entirely different configuration that I find to be much faster and easier to use. In this post I will show screencasts of the features I’m using and provide my entire init file at the end. There should be enough comments in the init file to make it clear what’s going on. If not leave a comment and I’ll try to explain.
I use Edit: I’ve started using EIN to be able to edit Jupyter
notebooks inside the GUI Emacs. While most of my work is still in the
terminal, I now have more confidence that this configuration works well
on both GUI and nox Emacs.
emacs-nox, i.e. a non-graphical Emacs. You may have
to perform some minor changes to get things to work in the graphical
Overview of Changes
First I’ll just briefly outline what I changed and why.
- Use Emacs server-client: faster startup when opening emacsclient than when opening Emacs
- Better battery use: RTags is way too CPU intensive for what it offers
- Better tags navigation: again, RTags uses too much CPU (really bad for a laptop), and it also doesn’t scale well to really large projects that have more than 100,000 lines of C++.
- cmake-ide is clumsy: that’s just it. It requires a lot of configuration for each individual project, and depends too heavily on RTags
- Autocompletion using company-mode with semantic, irony, and rtags is really slow, especially with large projects
- Ivy turns out to be a faster, more lightweight alternative to Helm that suites my needs just fine.
The biggest reason that I continued investigating alternative configurations is that RTags was just way too CPU intensive. It would use up all 8 hyperthreads if I let it, and every time I changed something in a low-level header file it would re-parse the entire project. This was just way too expensive on a laptop. It might be okay if you have a powerful desktop and don’t care about battery life, but when you’re on the go it’s just not a realistic implementation.
Faster Startup - The Emacs Server and Client
One thing that can be annoying as an Emacs configuration grows in complexity is the increased startup time. There are a few ways of dealing with this. One that looks promising but I have not tried yet is [use-package][se-package]. The basic idea seems to be loading packages lazily so that the total load time is spread out rather than all at once.
I’ve opted for using the Emacs server-client approach. What this
means is I start Emacs once at login using systemd, then connect
to the running session using the emacsclient. The alias I use to
connect to Emacs is
alias ec="emacsclient -c". My systemd
file is in
~/.config/systemd/user/emacsd.service and contains:
The important part is the
Environment=SSH_AUTH_SOCK on line –
this ensures that you have access to your SSH agent from within
the Emacs session. Without this line
you will need to re-enter your SSH key’s password each time you use it.
Lines 14-18 add to various
PATHs that I need for my work. Once you’ve
created the file run
systemctl --user enable emacsd.service && systemctl --user start emacsd.service
to start the backgrounded Emacs process and also set it to start at login.
The Emacs daemon can be restarted using
systemctl --user restart emacsd.service.
Ivy and Swiper
I’ve switched to using Ivy for fuzzy matching instead of
Helm. Ivy is quite a bit smaller than Helm because it only
serves as the underlying completion engine that other packages
plug in to. The important thing to note is that I also use ripgrep
for faster searching. If you do not or cannot install
ripgrep then just remove any lines referring to
rg from my
init file. In the screencast below I show the use of Ivy’s fuzzy matching when
opening a file, as well as when using
project-find-file. For ease-of-use
C-x M-f to
project-find-file. Because of this I haven’t
really found a strong reason to use projectile.
Another useful plugin that builds on top of Ivy is swiper, which replaces the standard search in Emacs. Rather than having to manually jump through the file, swiper shows all the matches in an extended minibuffer. This means that forward and reverse search are effectively the same and both can be remapped to swiper.
Navigating the Code Base With Tags
Similar to RTags, there are CTags, and GTags. These allow
you to rapidly navigate the code base by jumping to the definition of a class
or function. For example, say I want to see the definition of a function
that’s used in the code I’m looking at. Well, I can jump to the definition
M-.. Once I’ve
understood what I needed to from the function definition I can jump back
to where I was previously by pressing
M-t shows all the
occurrences of the word-at-point in the tags database. Hopefully this makes
the use case for tags quite clear. What I wanted was a fast-parsing, and
accurate tag implementation. After trying around five different ones
I finally settled on Universal-CTags as the generator for the tags
database. The first step is installing Universal-CTags on your
system. You should verify you have Universal-CTags installed and not some
other implementation by running
For navigating the tags inside Emacs I use counsel-etags, which works really well despite being quite young. My configuration triggers a rebuild of the tags database every time you save a file in the project and 3 minutes have elapsed since the last time a rebuild was triggered. This ensures navigation to new classes and functions is possible. Note that as of this writing I override the provided auto-update function with one that is capable of using wildcards in both file names and directory names. By default only file names support wild cards. Below is a demo of the source code navigation.
Pretty Code With ClangFormat
If you aren’t using ClangFormat you should very seriously consider it. Here’s my simple Emacs config for it:
1 2 3 4 5 ;; clang-format can be triggered using C-c C-f ;; Create clang-format file using google style ;; clang-format -style=google -dump-config > .clang-format (require 'clang-format) (global-set-key (kbd "C-c C-f") 'clang-format-region)
Syntax Highlighting for C++11 and Beyond
The builtin syntax highlighting doesn’t do a very good job when it comes to modern C++. Luckily there’s a remedy: modern-cpp-font-lock. Configure using:
1 2 (require 'modern-cpp-font-lock) (modern-c++-font-lock-global-mode t)
YouCompleteMe - Fast Code Completion (UPDATE(14/10/19): Switching to lsp-mode+clangd)
The two most important parts of code completion speed and accuracy. If either of these is not outstanding then the code completion will not be useful to a seasoned developer. A third criteria that is important for me is that the code completion engine uses less CPU resources than compiling the code would, otherwise I might as well just use the compiler to give me suggestions. I also want to be able to use code completion when I’m traveling and low CPU usage means better battery life. The best solution that I’ve found is the YouCompleteMeDaemon with emacs-ycmd. ycmd uses libclang for finding completions and so is accurate and fast, even with large projects. Additionally, it only parses the file you currently have open, unlike some completion frameworks that would re-parse the entire project.
First you must install the ycmd server, for which instructions are
available here. Next install the emacs-ycmd
package in Emacs, which hooks into company and
flycheck to provide completions and on-the-fly syntax
checking. In the screencast below I show the use of the code completion and
syntax checking features together to output the size of a container to
standard out. The error message that appears at the end in the minibuffer
tells us that the
<iostream> header was not included.
In my init file I have separated the setup of ycmd, company, and flycheck into three different sections for easier maintenance in the future. With ycmd, company, and flycheck I get really fast and really accurate completions with my CPU idling most of the time, so I also get great battery life. Finally, mission accomplished!
I use YCMD for a fairly complex C++14 project that uses many new language
features and has a lot of class and function templates. To get really good
code completion I’ve developed a python script for YCMD that very
aggressively finds compilation flags for header files. The reason such a
script is necessary at all is because a
compile_commands.json file does
not contain any compilation flags for header files, since they aren’t
compiled. I’ve shared the script as a Gist here.
The script must be placed at
~/.ycm_extra_conf.py for the Emacs
configuration to find and use it. If you do not want to use the
script, then remove the lines
1 2 3 (set-variable 'ycmd-extra-conf-whitelist '("~/.ycm_extra_conf.py")) (set-variable 'ycmd-global-config "~/.ycm_extra_conf.py")
from the Emacs init file.
Another thing to be aware of is that getting YCMD, or more specifically
libclang, to play nicely with precompiled headers took some work. See
this issue on the YCMD GitHub for details. The short
story is that if you use precompiled headers you might have to build
YCMD using your system libclang by passing
the build script.
LSP mode and clangd (UPDATE 14/10/19)
I’ve recently switched from YCMD to using lsp-mode and clangd. With the release of clang 9, clangd has received a lot of critical features (in my eyes) and is now at a point where I can use it in my day-to-day work. lsp-mode uses the Language Server Protocol (LSP), which provides a language-agnostic standard for completion/syntax checking engines like clangd or the python-language-server (pyls) to communicate with an IDE. The configuration for lsp-mode is quite simple and I don’t see the need to provide customization points that I provided with YCMD. If I’m wrong please let me know in the comments or file an issue on the GitHub repo where I keep my environment files. I still use company as the completion frontend so the GIFs are mostly up-to-date, except that clangd seems to be better at completion than YCMD in my experience.
Git Source Code Management
I also perform all my git operations inside Emacs using magit, and use git-gutter to show me which lines I’ve changed in the current file. Magit is extremely feature rich and I highly recommend reading through the lengthy documentation. You will very quickly save the time you invest by no longer typing out long git commands. There are also screencasts available on the magit site, so I won’t show any here.
Fast Startup Time
Note: This section was added on Feb. 10, 2018. The functionality of the configuration does not change, but it is faster to load.
I don’t do much python development and I especially try to avoid notebooks, but
sometimes I have no choice. I find web browsers to be a terrible
development environment and so I’ve started using EIN for editing
Jupyter notebooks. This makes the process much more tolerable. Unfortunately,
starting a Jupyter server when starting Emacs takes ~2.5s, which is a long
time. I use an Emacs server on my development machine, but when working on a
supercomputer I typically don’t, or still have to have it load when I log in. I
decided to do some research and use
use-package to speed up the
load time. The result is that my Emacs startup time is down to ~0.6s from
~4.7s without loss of functionality. While I’d love to have it be 0.1s, 0.6s
makes the startup time very tolerable. I won’t say more about this other than
that I’ve shared my most recent version of my
~/.emacs.el file in the
Gist GitHub repo here.
My init File/Installation
I’ve shared my init file as a
Gist GitHub repo here. The
you will need to do to have it completely replace your current configuration
are install ycmd and change the path to where you installed ycmd
/home/nils/Research/ycmd in the
.emacs.el file). To ensure
Emacs loads the new init file make sure that you do not have an
~/.emacs.d/init.el file. Make sure you have an internet
connection when you start Emacs because it will download
and install any missing or outdated packages automatically for you. If
everything is correct you should not receive any errors or warnings in
I’ll now provide a step-by-step guide to installing my configuration.
- Emacs 24.5 or newer
YCMD and its requirements (e.g. glibc version 2.14 or newer)
- clangd for C/C++ completion (I recommend version 9 or newer)
- pyls for python code completion and syntax checking
- bash-language-server if you want bash syntax checking and code completion
- Rust language server if you want rust completion and syntax checking
- ripgrep (optional, remove from init if you don’t have it)
- Make a copy of your
~/.emacs.el, as well as
~/.emacs.d/init.el, whichever you use
- Copy the
GistGitHub repo .emacs.el to
- Start Emacs. If Emacs does not start installing packages immediately press
list-packages, then close and start Emacs again.
- If any packages fail to install automatically, press
list-packagesto install them manually, though most will install automatically.
/home/nils/Research/ycmd/ycmdwith the path to wherever you’ve chosen to install ycmd and restart Emacs.
- Copy the ycmd Gist to
Note: On one machine I installed this configuration on I had to comment out
(require 'yasnippet) section, start Emacs and let everything install,
then uncomment that section and restart Emacs.
In this post I gave a fairly brief overview of the major changes I’ve made to my Emacs configuration. I’ve put in a fair amount of effort into cleaning up and organizing my Emacs init file, so hopefully sharing it here is enough to get you started. If not, please leave a comment on what you want an explanation on and I’ll update this post with more information.