Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

Hacker News Discussion ↗

Reimagining Emacs from scratch exposes a core tension between preserving its identity as a Lisp-powered, infinitely extensible environment and modernizing it for performance, security, and broader appeal. Many would keep a Lisp at the heart (or swap Elisp for Scheme/Common Lisp) and focus on concurrency, lower latency, better large-file handling, and a more modular architecture, while others argue for mainstream languages like Python, Lua, or JavaScript, or even WebAssembly-based plugins. Proposals also range from safer, sandboxed extension systems and saner defaults to improved typography, GUI behavior, window management, and collaborative editing—often with the caveat that too much change risks creating something powerful but no longer recognizably Emacs.

Language and Extensibility

  • Central tension: Emacs as a “Lisp machine” vs desire for a more mainstream extension language.
  • Many insist Lisp (esp. Emacs Lisp or another Lisp like Common Lisp, Scheme, Guile, Fennel) is essential to Emacs’ identity and unique REPL-driven, homoiconic metaprogramming.
  • Others argue for Python, Lua, JavaScript/TypeScript, or even a language-agnostic bytecode / WASM core, to broaden accessibility.
  • Some want Elisp kept but modernized (lexical scope by default, better namespacing, richer data structures), or replaced with a CL/Scheme-like core while preserving backward compatibility.

Security and Sandboxing

  • Some see little need for sandboxing extensions, emphasizing user freedom, source visibility, and trust in archives.
  • Others highlight supply-chain risks, auto-updating packages, and argue for fine-grained capabilities (e.g., themes shouldn’t exfiltrate code) or WASM-style sandboxes.
  • Disagreement persists on whether security constraints inherently undermine Emacs’ ethos.

UI/UX, Input, and Layout

  • Calls for better typography, proportional fonts, non-Latin script support, and “harder to misconfigure” defaults.
  • Mixed views on mouse and GUI behavior; Emacs often feels “keyboard-first” and odd compared to modern GUI editors.
  • Keybinding debates: keep Emacs-style Ctrl/Meta vs default to leader-key / modal (Vim-like) interaction; some suggest more CUA-like defaults or dedicated beginner modes.
  • Window management is powerful but seen as complex and unintuitive; newer APIs (e.g., display rules) help but don’t fully satisfy everyone.
  • Several want off-screen cursors and scrolling behavior consistent with other editors.

Architecture, Performance, and Concurrency

  • Many would redesign the core for true concurrency, async I/O, and non-blocking UI, plus better handling of large files and many buffers.
  • Proposals include Rust or other safe languages for the core, more sophisticated buffer structures (ropes/piece tables), and cleaner separation between core, display, and worker processes.
  • Some report Emacs as “clunky” or high-latency compared to Neovim; others say modern Emacs (with native compilation, tuning, daemon mode) already feels fast.

Ecosystem, Workflow, and Philosophy

  • Suggestions for improved package management, discovery, and possibly paid plugin “app stores”; others prefer a tiny core with everything else in packages.
  • Criticism of the email/patch-based contribution workflow; some want GitLab/sourcehut-style interfaces.
  • Strong recurring theme: Emacs is not “just an editor” but a programmable, Lisp-centric environment; many proposals are judged by whether they preserve or dilute that character.