Bad NEWS, Emacs

Original Article ↗ Hacker News Discussion ↗

A controversial change to Emacs’s register feature—introducing an extra confirmation step and altering decades‑old keyboard workflows—has triggered strong reactions among long‑time users. Critics argue that breaking muscle memory and not initially providing a simple way to restore the old behavior shows disregard for backward compatibility and Emacs’s ethos of extreme customizability, while others counter that master is a development branch and UX improvements for newer users are legitimate goals. The debate has expanded into broader questions about project governance, how and when it is acceptable to break established interfaces, and whether such changes should always be optional or opt‑in.

What changed and why it matters

  • Change affects Emacs “registers” (advanced multiple-clipboard / position feature), not normal copy/paste.
  • New behavior interposes a minibuffer UI that shows registers and requires an extra RET to confirm.
  • Critics say this turns a fast, home-row, muscle-memory operation into a modal, slower one used many times per minute.
  • Several analogies: like forcing a confirmation dialog after every Ctrl-C/paste or adding latency to a musician’s instrument.

Impact on users and workflows

  • Heavy register users report broken muscle memory, broken macros, and added cognitive load.
  • Some emphasize that small per-action delays compound badly in workflows used hundreds of times a day.
  • Others say registers are niche; many long‑time users barely use them and see the conflict as overblown.
  • Non‑Emacs users in the thread use Vim analogies and agree such a change would be disruptive in their editors too.

Configurability and need for a fork

  • One camp: in Emacs “everything is Lisp,” so users or packages can easily restore old behavior; a hard fork is seen as political or ego‑driven.
  • Another camp: monkey‑patching core behavior is effectively maintaining a private fork anyway and shifts maintenance burden onto users.
  • There is ongoing work on options/toggles to restore old behavior; some earlier proposals were rejected for also removing other new features.

Development process and project governance

  • Concern that a breaking UX change for long‑standing behavior landed on master after discussion among very few developers.
  • Some argue this is exactly how the dev branch is supposed to work: merge, then refine or revert based on feedback before release.
  • Others see a pattern of “fiat” decisions, poor respect for backward compatibility, and slow willingness to revert.
  • Multiple commenters note the article’s framing is highly one‑sided; mailing‑list threads show more nuance and active iteration.

Broader design philosophy and “new vs old” users

  • Debate over whether Emacs should optimize defaults for newcomers (discoverability, safety) versus power users (speed, stability).
  • Many say breaking decades of keybindings should be rare, opt‑in initially, and always revertible by a clear setting.
  • Some see this as emblematic of a wider trend: UX “improvements” that disrespect muscle memory across many software projects.