Two Years of Emacs Solo
Emacs power users are reflecting on a “solo” approach: relying almost entirely on built‑in features and hand‑rolled Elisp instead of external packages to gain stability, deep understanding, and precise control of their editor. Commenters weigh this ideal against the time cost and complexity of heavy customization, sharing practical tips on LSP integration, backup behavior, Tramp, and keybinding ergonomics, while debating whether re‑implementing functionality is worth it compared to reusing packages. Many note that modern tools like LLMs can now bridge the gap, making it easier to evolve highly tailored Emacs setups without sacrificing productivity.
Custom tooling & “solo Emacs”
- Several commenters strongly relate to writing small bespoke Elisp tools instead of relying fully on external packages.
- Example: a custom region-expansion function driven by user-defined delimiter sets and trigger keys, used alongside treesitter plugins for fine-grained selections.
- Some hesitate to open-source such code due to edge cases, maintenance burden, and user expectations.
- Others see “solo” setups as a way to deeply understand Emacs, while acknowledging the time and discipline required.
Packages, ELPA, and learning Elisp
- One camp argues the “no external packages” motivation is weak: core vs ELPA is historically arbitrary, and many built-ins get fixes only via ELPA.
- Strong pushback on the claim that “writing your own packages is the best way to learn Elisp” if taken alone; reading others’ code is seen as crucial.
- Defenders clarify that the solo approach still studies many existing packages and treats it as a fun learning challenge.
- Some suggest copying small chunks of open-source packages into configs instead of full rewrites.
LSP: Eglot vs lsp-mode for C++
- Consensus: feature quality and performance depend mainly on the underlying C++ LSP (e.g., clangd), not on Eglot vs lsp-mode.
- Multiple reports that Eglot works “pretty much” on par, sometimes more reliably and with less setup.
Lisp and Emacs architecture
- Discussion on whether Lisp is inherently better for editors.
- Historical context: Emacs grew from Lisp-heavy environments; today, Lisp’s dynamic, incremental nature and code-as-data model still fit Emacs’ live-hacking style.
- Some note that most of Emacs is written in Elisp on top of a C core; others mention alternative extension languages in other editors.
Backups, autosave, and defaults
- Strong dislike for Emacs’ default tilde-suffixed backup files, especially when editing config directories like nginx’s.
- Many share snippets to redirect all backups to a single directory or disable them entirely; some also disable lockfiles.
- Debate over whether Emacs or tools like nginx should adapt; some argue these backup conventions predate modern daemons, others call it directory “pollution.”
- General agreement that Emacs is easy to reconfigure, but disagreement on what its defaults “should” be.
Emacs UX: keyboard vs GUI, learning curve
- Some are impressed by hardcore keyboard-centric setups but prefer GUI-oriented editors like Zed or Sublime.
- Others argue the power comes precisely from dense keybindings and muscle memory; menus cannot replicate that efficiently.
- Tools like which-key and built-in tutorials are recommended as bridges for newcomers.
- Many run Emacs as a GUI app; some still prefer terminal + tmux, others advocate TRAMP for remote editing.
Emacs + LLMs
- Multiple reports that LLMs are already effective at writing and debugging Elisp and Emacs configs.
- Emacs’ text-centric, highly programmable environment is seen as a promising “OS” for agents, lowering the barrier to deep customization.
Overall sentiment
- Broad admiration for the solo configuration as a learning exercise and reference.
- Recurring tension between maximal customizability and the time cost of tinkering versus “just getting work done.”