In Praise of (modern) Vanilla Emacs (29+)
If we were to plot Emacs configurations on a geometric space based on their complexity, a simple metric to use would be the distance from vanilla Emacs, i.e. the amount of key rebinding and/or function overrides being done to the default, vanilla Emacs configuration.
In this (admittedly one-dimensional) space, sitting on one extreme (most modifications) would be Emacs distributions such as spacemacs or Doom Emacs, which seek to remold Emacs into an entirely different modal editor, with Vim-like keybindings. Some packages, such as ergoemacs, may rebind enough of the default key bindings to warrant their inclusion in this region.
On the other extreme (least modification), we have the vanilla, or "default" Emacs configuration, and adjacent "starter configurations" such as bedrock, which apply a set of modernized settings to Emacs' built-in packages.
Predictable Keybinds, Faster Startups
Vanilla, default, or "minimalist" Emacs configurations enable a faster start-up, as less elisp code gets evaluated as part of Emacs' initialization process. This eliminates the need for running Emacs in server mode, and makes starting & running several ad-hoc Emacsen viable, as each Emacs instance can be started in less than a second.
Aside from startup performance, staying close to the defaults ensures that the configuration is usable by other Emacsers without any special guidance, using key bindings that are familiar to them. Many Elisp programs, snippets, or packages also assume a close-to-default environment. Overall, on a close-to-vanilla configuration, the potential for conflicts, incompatibilies, and general breakage remains low.
Viability
Since version 29, Emacs can provide a powerful, modern editing experience with only a modest amount of custom configuration. Bedrock consists of ~119 non-comment lines. And my own configuration is around ~173 lines long. Both only pull a minimum amount of external packages (Bedrock pulls which-key for discoverability, and my configuration pulls markdown-mode for documentation buffer formatting when using eglot).
In my opinion, a number of factors contributed to this:
- (f)ido-mode, icomplete and variations thereof such as fido-vertical-mode (Emacs 28+) are built-in into Emacs, and are viable replacements for vertico and other 3rd-party minibuffer completion packages.
- undo-no-redo (Emacs 28+) provides a traditional undo functionality, although it is disabled by default.
- The built-in completion-at-point function, and the \*Completions\* buffer have both gotten various usability upgrades in Emacs 29.
- tree-sitter is part of core Emacs (29+), enabling simple structural editing.
- eglot is part of core Emacs, providing Emacs with language server support out of the box.
- project.el is built-in and automatically detects projects under VCS by default.
- The modus and leuven themes are bundled with Emacs, both offering usable dark themes.
Other niceties such as use-package (built-in as of Emacs 29+) may not directly affect the editing experience, but allow for succinct and less-verbose configuration.
The Optimum
New Emacs users often make the mistake of assuming that a modern editing experience requires a full-fledged distro like spacemacs or Doom. This may have been true to an extent is the past – indeed, installing a full distribution like spacemacs used to save a considerable amount of customization time, configuring and installing packages.
However, I would argue that the last two major Emacs releases (28, 29) make simpler, more minimalist Emacs setups more viable than ever. In the very least, for most people, the number of external packages they need to install should be reduced, so that only a handful of external packages are necessary. In that sense, the optimum (for most people) should be somewhere around the vanilla cluster with less complex, mostly-straightforward customizations.
