4 ms·

Aside from what the article focuses on (being selective about which packages to install in the first place), I feel that making extensive use of the (use-packa

Aside from what the article focuses on (being selective about which packages to install in the first place), I feel that making extensive use of the (use-package ...) macro keeps a large Emacs config manageable. It gives things a very standardised structure, as opposed to the config being pages and pages of arbitrary Lisp code of different vintages. https://www.gnu.org/software/emacs/manual/html_node/use-package/index.html https://www.gnu.org/software/emacs/manual/html_node/use-pack...

sokoloff 2y ago
I switched to using org-babel to manage my emacs config and it’s been helpful to keep things organized (and half-documented when I come back to it months later). David Wilson has a good YouTube on the topic: https://www.youtube.com/watch?v=kkqVTDbfYp4 https://www.youtube.com/watch?v=kkqVTDbfYp4
- codemonkey-zeta 2y ago
  This is the best method I've found for managing emacs config complexity. I have thousands of lines of configuration in a single file, but the whole structure feels "not that big" because it is all organized into a logical hierarchy, with the gritty details hidden a few layers down, yet easily navigable with ordinary search features.
sidmitra 2y ago
I second this, although i use `elpaca with use-package` instead: https://github.com/progfolio/elpaca https://github.com/progfolio/elpaca It helps me keep the config consistent regardless of if something comes from MELPA, or bitbucket/github/gitlab etc. - I also keep my config in README.org an github which shows the preview by default - Org mode also helps me keep the commentary alongside. I can even just mark stuff as TODO, COMMENT with keyboard shortcuts. Infact if you read the source instead you'll find parts with COMMENT that don't render in the default preview on browser on Github. - The git + github bits ofcourse help me use branches/PRs where i can test out stuff. Eg. most recently i was trying out lsp-bridge over eglot. Here's my literate config: https://github.com/sidmitra/emacs.d https://github.com/sidmitra/emacs.d PS: Over time some bits have moved back to init.el to take precedence rather than everything in the org file.

sokoloff 2y ago

I switched to using org-babel to manage my emacs config and it’s been helpful to keep things organized (and half-documented when I come back to it months later). David Wilson has a good YouTube on the topic: https://www.youtube.com/watch?v=kkqVTDbfYp4 https://www.youtube.com/watch?v=kkqVTDbfYp4

codemonkey-zeta 2y ago
This is the best method I've found for managing emacs config complexity. I have thousands of lines of configuration in a single file, but the whole structure feels "not that big" because it is all organized into a logical hierarchy, with the gritty details hidden a few layers down, yet easily navigable with ordinary search features.

sidmitra 2y ago

I second this, although i use `elpaca with use-package` instead: https://github.com/progfolio/elpaca https://github.com/progfolio/elpaca It helps me keep the config consistent regardless of if something comes from MELPA, or bitbucket/github/gitlab etc. - I also keep my config in README.org an github which shows the preview by default - Org mode also helps me keep the commentary alongside. I can even just mark stuff as TODO, COMMENT with keyboard shortcuts. Infact if you read the source instead you'll find parts with COMMENT that don't render in the default preview on browser on Github. - The git + github bits ofcourse help me use branches/PRs where i can test out stuff. Eg. most recently i was trying out lsp-bridge over eglot. Here's my literate config: https://github.com/sidmitra/emacs.d https://github.com/sidmitra/emacs.d PS: Over time some bits have moved back to init.el to take precedence rather than everything in the org file.