HN Debrief

Emacs 31 is around the corner: The changes I'm daily driving

  • Programming
  • Developer Tools
  • AI
  • Open Source

The post is a hands-on tour of Emacs 31 from someone already running pre-release builds. It highlights quality-of-life upgrades that long-time users have wanted in core for years: automatic Tree-sitter grammar installation, editable xref buffers, built-in frame and window transposition, terminal and markdown improvements, and small paper-cut fixes like making C-w kill a word backward when no region is selected. None of this is a reinvention of Emacs. The point is that more of the "modern editor" baseline is moving from scattered packages and shell hacks into stock Emacs.

If you dismissed Emacs as too much setup for too little payoff, Emacs 31 plus AI-assisted config changes that tradeoff. The practical question is no longer whether Emacs can match modern editing workflows, but whether your team benefits enough from a programmable, durable tool to justify a steeper personal setup curve than VS Code or an IDE.

Discussion mood

Strongly positive. People were excited that Emacs 31 folds long-requested capabilities into core, cuts down on custom config, and makes Emacs feel more current. The main friction points were the usual ones: startup and platform performance, too much configuration for newcomers, and skepticism that the defaults are modern enough without external presets.

Key insights

  1. 01

    Terminal support is now an AI workflow battleground

    New terminal work inside Emacs is not cosmetic. It is about making Claude Code and other terminal-native coding agents usable enough that people stop jumping out to VS Code or a standalone terminal. Ghostel was singled out as materially better than vterm for this use case because it handles modern escape sequences, animated TUIs, resizing, notifications, progress reporting, drag and drop, and clickable file links. That reframes terminal improvements as part of editor competitiveness in the agent era, not old-school shell nostalgia.

    If your team is experimenting with CLI coding agents, test terminal integration as a first-class editor feature. Weak terminal support now directly degrades AI-assisted workflows.

      Attribution:
    • baokaola #1 #2
    • dakra #1
    • bryanlarsen #1
  2. 02

    Emacs regained credibility through shared infrastructure

    The persuasive case for Emacs was not "it can do anything." It was that Tree-sitter and LSP reduced the old tax of every language ecosystem maintaining its own fragile mode stack. That gave the project more leverage, because upstream improvements now benefit many languages at once. People who had stopped being impressed by release notes said that this shared substrate made recent releases feel alive again and narrowed the gap with mainstream IDEs enough that Magit, layout density, and custom workflows can carry the rest.

    When evaluating editor platforms, pay attention to whether they are gaining leverage from common infrastructure or still depending on bespoke per-language glue. Shared foundations are what make an old tool start improving faster instead of slower.

      Attribution:
    • jerf #1
    • jcgrillo #1
    • TacticalCoder #1
  3. 03

    LLMs make Emacs valuable as a one-off toolmaker

    One concrete example stood out because it was not about polishing a config. A commenter had ChatGPT write a tiny Elisp function that previewed remote images referenced inside a tagged text file over TRAMP. The point was not that this is impossible elsewhere. It was that Emacs makes weird, personal workflows cheap to turn into working software inside the same environment where the work already happens. AI lowers the skill barrier, but the payoff depends on the host editor being programmable enough to absorb the result.

    Use Emacs-like environments where bespoke tools can live next to the work, not just around it. AI helps most when it can cheaply produce small workflow-specific utilities instead of only generating code for your main product.

      Attribution:
    • whacked_new #1
  4. 04

    AI-generated configs need capability limits, not just diffs

    People were enthusiastic about asking an agent to rebuild a Doom setup as a lean vanilla init.el. The sharpest addition was that this is safe only because init.el is easy to diff and rollback. Once an agent starts installing packages, shelling out, or mutating your dotfiles repo, an audit trail after the fact is not enough. The useful control is a capability boundary before the action, plus tamper-resistant logging if you let the agent touch anything with side effects.

    Treat editor config as a good sandbox for AI-assisted automation, then stop and add explicit permissions before expanding that pattern to package managers, shell hooks, or system setup. Reviewability is not the same thing as containment.

      Attribution:
    • bryanlarsen #1
    • killix #1
    • quibono #1
    • iLemming #1
  5. 05

    The real onboarding problem is choosing defaults

    The most credible criticism was not that Emacs cannot be modernized. It was that new users have to decide among too many half-overlapping ways to get there. Tree-sitter, Eglot, themes, completion stacks, starter kits, and distro-like configs all exist, but "easy to install" does not solve the cognitive load of choosing, understanding, and debugging them. Several people wanted upstream presets or a guided config generator because the missing piece is not raw flexibility. It is a trustworthy starting point.

    If you introduce Emacs inside a team, standardize a baseline yourself instead of expecting each developer to discover the right package stack. The adoption cost is mostly decision fatigue, not package installation.

      Attribution:
    • tpmoney #1
    • coldtea #1
    • chipotle_coyote #1
    • quibono #1
  6. 06

    Daemon mode is becoming session infrastructure

    Long-running Emacs server setups were described less as a startup optimization and more as a replacement for tmux or screen. People use emacs --daemon and emacsclient for persistent buffers, quick reconnects, portability across machines, and even inside agent sandboxes. That matters because it turns the editor into the session manager for both human work and AI-assisted work, with state that survives terminals and remote hops.

    If startup time or remote continuity is your blocker, test daemon plus client mode before writing Emacs off. It changes the operating model enough that old complaints about process startup become much less relevant.

      Attribution:
    • noufalibrahim #1
    • bryanlarsen #1 #2 #3

Against the grain

  1. 01

    Some upstream changes still feel bolted on

    The harshest pushback came from a user who does want newer platform support but dislikes the implementation tradeoffs. They argued that native compilation via trampolines increases attack surface and complicates debugging, and said Wayland PGTK builds appear to force native compilation in practice. Even if that specific coupling is a bug, the complaint lands because it points at a familiar Emacs pattern: features arrive, but sometimes with internals that feel more accumulated than cleanly designed.

    Do not confuse visible feature progress with architectural simplicity. If you run Emacs in security-sensitive or heavily customized environments, inspect the implementation details before upgrading for one marquee feature.

      Attribution:
    • hollerith #1 #2
    • vkazanov #1
  2. 02

    Mouse and GUI workflows still feel second class

    Not everyone sees Emacs 31 as evidence that Emacs is broadly usable. One commenter rejected the keyboard-centric model outright and said the mouse experience remains awkward, performance is uneven, and everyday polish can still feel janky in ways that make basic GUI editing unpleasant. That does not undercut Emacs for committed power users, but it does limit how far "modern editor" claims travel outside that audience.

    If your users prefer pointer-heavy workflows or expect polished GUI conventions by default, Emacs is still a bad fit regardless of how much stronger its internals have become.

      Attribution:
    • ux266478 #1
  3. 03

    AI may reduce how much coding features matter

    A quieter dissent was that AI changes the role of the editor itself. One person noticed LSP had been broken for a week without them caring, because they were editing less directly. Others replied that Emacs remains indispensable for Magit, Org, mail, RSS, and general text-based life management. That shifts the value proposition away from language tooling alone and toward being a durable command center for adjacent work.

    When choosing editor investments, separate code-intelligence features from the broader workflow surface. AI can blunt the payoff of advanced coding assistance while increasing the value of tools that manage review, notes, git, and task context.

      Attribution:
    • ddrake18 #1
    • TFNA #1
    • bryanlarsen #1

In plain english

Eglot ↩
The built-in Emacs client for the Language Server Protocol.
Elisp ↩
Emacs Lisp, the Lisp dialect used to configure and extend Emacs.
init.el ↩
The main Emacs configuration file where users customize behavior with Emacs Lisp.
LSP ↩
Language Server Protocol, a standard way for editors to talk to language-specific servers for features like autocomplete, jump-to-definition, and diagnostics.
Magit ↩
A Git interface for the Emacs editor that exposes many Git operations through interactive commands.
MELPA ↩
Milkypostman’s Emacs Lisp Package Archive, the most widely used community package repository for Emacs.
native compilation ↩
An Emacs feature that compiles Emacs Lisp into machine code for better performance.
PGTK ↩
Pure GTK, an Emacs build variant that uses the GTK toolkit directly and is often discussed for better Wayland support.
tmux ↩
A terminal multiplexer that lets users keep multiple persistent shell sessions and panes in one terminal.
TRAMP ↩
Transparent Remote Access, Multiple Protocols, an Emacs feature for editing remote files as if they were local.
tree-sitter ↩
A parser system often used by developer tools to analyze source code structure precisely.
VS Code ↩
Visual Studio Code, a popular code editor from Microsoft that is built with web technologies inside a desktop app shell.
vterm ↩
An Emacs terminal emulator package designed to provide a fast, full-featured terminal inside Emacs.
Wayland ↩
A modern Linux display protocol that handles how applications draw windows and talk to the screen, intended to replace the older X11 system.
xref ↩
Emacs cross-reference support for finding definitions, references, and related code locations across a project.

Reference links

Emacs tools and packages

  • Ghostel
    Suggested as a faster and more capable Emacs terminal for Claude Code and other agent workflows.
  • Ghostel feature comparison
    Used to compare Ghostel against vterm and explain why it handles modern terminal workflows better.
  • emacs-hnreader
    Mentioned as an Emacs reader for Hacker News.
  • Bedrock Emacs
    Recommended as a lighter preconfigured starting point for users who want sane defaults without a full Emacs distro.
  • Casual
    Shared as a package aimed at improving feature discoverability in Emacs.
  • Anju
    Shared alongside Casual as another package focused on better interaction and discoverability.

Background and reference material

  • GNU Readline
    Referenced to explain why Emacs-style keybindings appear across many shells and command-line tools.
  • Mastering Emacs
    Recommended as a still-relevant guide for experienced users who have not kept up with modern Emacs.
  • Wayback Machine copy of the post
    Shared because the original site was briefly failing under traffic.

Historical and cultural references