My Development Environment

GNU Emacs has been my favourite editor for almost 15 years (my .emacs is public for anyone interested). Before that I hopped from editor to editor. Among the more notable ones are Crimson Editor or Geany for general coding and Kile for LaTeX. I also used Netbeans or Eclipse for C/C++ stuff and CBFortran for Fortran. During the last two years I’ve switched almost entirely to VS Code and started modernising and upgrading my development environment.

Why I left Emacs

Emacs is great. It offers unmatched flexibility. My most used modes are probably Org Mode for organising all my notes and AucTeX for writing LaTeX. But there are hundreds of more available in package repositories like Melpa.

Once you get the hang for the keybindings you can move around in your code extremely fast and perform pretty much any imaginable task.

If that’s not enough, you can customize every little aspect of your environment. A large part of Emacs is written in Lisp and you can hook into most functions and change it to your liking.

However, I think that’s also one of the biggest downsides of Emacs. Many packages require you to add Lisp code to your config to get it running, which can be quite a hurdle.

Another issue is that for certain tasks there are multiple solutions available, and it’s often quite difficult to understand which one you should choose. Want code completion? Fine, you can choose between company mode, company-lsp, lsp-mode, ccls, eglot, clang-capf, ac-clang, irony, …

I must confess that I never got code completion running properly.

Getting new functions set up and running in a stable manner can be fun, but it’s also an enormous time sink.

What I like about Visual Studio Code

I think that by now, VS Code offers almost the same amount of configurability than Emacs. However, VS Code feels a lot more stable because you don’t have to fiddle around with lisp code to get things running. Code completion for most languages is two clicks away and debugging is a breeze.

The remote extensions in VS Code are among my favourites. I really like that you can connect to some running WSL instance or that you can hook onto a Docker container. VS Code supports so-called development containers, which I find are an amazing feature. WSL offers you a convenient Linux environment, but you can’t separate tools for different projects easily (at least as long as you stick to the package manager of your distro). Development containers also provide you Linux environments, but they are project specific. Tools and settings that you need for project X will never interfere with anything for project Y.

A project template for C++ and Fortran

I’ve created a small project template for C++ and/or Fortran development. The whole thing relies on the development containers in VS Code. Its main features are:

  • Most files (e.g. README, CONTRIBUTING, …) that one would expect in a project are available (albeit almost empty).
  • Support for clean git commit messages via git lint. Commits must follow the conventional commits specification.
  • Various hooks to ensure that whatever you commit is e.g. properly formatted. The hooks are set up via pre-commit. The following hooks are currently set up:
  • CMake support with presets to simplify its use with VS Code.
  • Vcpkg support (I actually prefer Vcpkg over Conan or Hunter).
  • Important tools (e.g. compilers) and extensions are predefined and will readily be available in the container.

The code formatting for Fortran relies on fprettify. As I couldn’t find a pre-commit hook for it, I wrote my own. It’s available on gitlab.

About Gitlab

Currently, all my projects are hosted on GitLab. In the past I’ve also used Github (because it’s popular) and Bitbucket (because it offered mercurial). Having everything in one place is very convenient and GitLab offers many features right out of the box.

Final Remarks

The development container is not ready for use. It needs some minor tweaking. You should for example ensure that your git name and email are set properly. According to this article it should work out of the box. For me, this was actually not always the case. I ended up adding my name and email to the .git/config file in the repo to get a consistent behaviour.

Similarly, SSH keys should work out of the box if your local SSH agent is running. This actually worked on my machine without me having to do anything. See these instructions for getting the SSH agent up and running if it doesn’t work for you.

Finally, it might be tricky to remember how to format your git commit messages so that git lint accepts them. It might be helpful to set up a git template for commit messages. You can specify one with the command

git config commit.template .gitmessage

See the git commit documentation for more information.

Notes

Creative Commons License This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

Mathematician and
Software Engineer

Researcher, Engineer, Tinkerer, Scholar, and Philosopher.

Related