How I organize my Emacs configuration

Leer en español

I am not going to share my Emacs configuration, but the way I keep it organized. I do not think I am discovering anything new, but it might be useful for someone who is starting to organize their configuration and does not know where to begin.

I do not use any framework (neither Doom nor Spacemacs) nor the literate approach of Org mode. Everything is vanilla Emacs and each file is an area of responsibility, while init.el acts as the index.

Why vanilla and not a framework? Frameworks decide for you. They lend you a huge configuration that you do not understand and that is hard to tweak. For me, the literate approach of Org is one more layer where something can break. I prefer the simplicity of the file I edit being the file that runs. The less magic, the fewer things that break.

So, inside my configuration folder (~/.emacs.d/), I have the following files:

  • "init.el": the index of my configuration. It loads the rest of the files in order.
  • "core.el": base Emacs behavior, such as handling backups, paths, clipboard, etc.
  • "functions.el": my personal scripts and macros.
  • "packages.el": repository configuration, such as MELPA (among others).
  • "ui.el": everything related to visual aspects: theme, modeline, typography, visual behavior, etc.
  • "ide.el": LSP, debugger, linters and programming configurations.
  • "plugins/init.el": third-party packages, each with its own configuration.

An example of a block you might find inside plugins/init.el:

;; ===
;; vterm-editor
;; Compose text in a full Emacs buffer and send it to vterm with a single keystroke.
;; Docs: https://git.andros.dev/andros/vterm-editor.el
;; ===
(use-package vterm-editor
  :ensure t
  :vc (:url "https://git.andros.dev/andros/vterm-editor.el")
  :after vterm
  :bind (:map vterm-mode-map
         ("C-c e" . vterm-editor-open)))

Each element is isolated in its own context. Using use-package lets me have an isolated and organized configuration block for each package.

I also have other satellite files for third-party packages, such as "plugins/feeds.el" for my RSS subscriptions, "plugins/erc.el" for IRC, "plugins/mu4e-config.el" for email, "plugins/gnus.el", etc. When they grow large and specific, I split them into individual files.

And why break it into areas instead of a single giant init.el? Because I want to know where to look without stopping to think. The brain appreciates each thing having its place, especially when you come back to it after months. Besides, each file is a piece I understand fully, because I wrote it myself. Over time your configuration stops being an editor and becomes a workstation tailored to you. It is my interface with the machine, and it should be as finely tuned as possible.

I am not saying this is the best way, but it makes it easy for me to know where to look and where to put things. Simplicity is also a feature.

Ayúdame a seguir escribiendo

Cada café me da un empujón para escribir el siguiente artículo.

Comentarios

Todavía no hay ningún comentario.

1 mención de otra web

Sigue leyendo