Tips/Tricks for avoiding a clusterfuck config & putting it on autopilot?

It appears that ppl. nowadays are putting everything into an **org-mode tangle config.** But even this it seems gets very long and cumbersome to maintain. I'm curious whether there are there any other tips/tricks that people use to reduce the mental load of carrying a custom config. Is the answer just simplification & reduction of the files? a custom org scheme? sticking to popular, maintained, high bus factor projects? Does anyone have a .emacs they havent had to touch or even think about for long periods of time?.. & are not completely bewildered when they come back to it (like i am when I pulled up my old college .emacs)? Curious to hear any suggestions/audacious tales/horror stories.

I might not be the best person to answer this, as I spend a ridiculous amount of time tweaking my init.el file. But that's probly more due to the particular phase of my life that I'm in. Plus I'm experimenting with a lot of different ideas. But anyhow, in the relatively short amount of time I've been using Emacs (a couple years, plus some time long ago when I learned the keybindings but not much else), I've tried a lot of different packages and methods. So I have a few ideas that might be helpful. 1. Start with the built-in options. Give them a shot. The fewer external packages you have to install, the simpler your config will be. 2. To that end, use package.el. Even if you like to pull things from github and run them, you can still install them with package.el using `package-install-file`. It's already there, and it works. And `package-list-packages` is really nice. 3. This might be controversial, but do `(setq custom-file "custom.el")` and at the bottom of your file, put `(load custom-file)`. Then, use the Customization interface for everything that allows it. It's a little bit clunky as a UI design, but other than that it works really well for setting variables. You won't have to concern yourself with whether to set a variable *before* or *after* a package has loaded. It's a just-works thing. And it clears up a lot of space in your config for things that are more important to you, like keybindings and setting up packages. So if you see that a variable was declared using `defcustom`, use Customization to set it. Emacs will take care of the rest. 4. As a related point, the "[helpful](https://github.com/Wilfred/helpful)" package shows you the source code of functions and variables whenever you use its drop-in replacements for describe-variable and describe-function. It even gives you a link to the Customization interface whenever you look up a variable that was declared with `defcustom`. A very useful external package. 5. Group any configurations related to a package together in a block for that package. Any setting that depends on a package should be grouped with that package. If you're using the "[use-package](https://github.com/jwiegley/use-package)" package that's easy. But if not, just put a comment at the beginning of each package block with the name of the package. But when you're binding a command from one package to a key that's in a keymap defined by another package, you have two related packages. In that case, put your `define-key` expression with the package that defines the command. But wrap it with `with-eval-after-load` to make that setting wait until the other package has created the keymap. Arrange the package blocks alphabetically by package name. 6. Rely on autoloads to load most packages. When these have been declared in a package, package.el sets them up for you automatically. And if you have "helpful" installed, you'll be able to see if the command is declared as an autoload when you run `helpful-callable`, which is helpful's replacement for `describe-function`. (You'll see ";;;###autoload" just above the defun or defmacro.) If the package author didn't set up the command to autoload, you can set it yourself using the `autoload` function. Once the autoload is defined, you either need a keybinding, a hook, or an entry in `auto-mode-alist` or `auto-interpreter-alist` to get the package to load... Or if you just want it to load on startup, use `require`. 7. Use built-in functions and macros to simplify your package configuration. That's what "use-package" is (a collection of macros), and it's a really amazing piece of work. But personally I've found that I don't need even a quarter of what it offers. I should point out, however, that using it was what got me to understand which commands I *should* be using in my config. They are: * with-eval-after-load * add-hook * add-to-list (for adding to auto-mode-alist and auto-interpreter-alist) * require * do-list * define-key * autoload Those functions are pretty much all I ever used "use-package" for. And it's not hard to create your own macros to shorten the names (or more) if you want. 8. "[page-break-lines](https://github.com/purcell/page-break-lines)" - This seems like a minor thing, but it's helped me with dividing my config into recognizable sections. Emacs has the concept of a "page" which is different from a screen, but has no set length. It's boundaries are wherever a "\^L" character is found. So this package makes a "\^L" appear as a horizontal line across the window. It's a little thing, but it's nice to have a clear demarcation between portions of your config. 9. Put frequently altered settings at the top of your config in `defvar` statements, along with the values you want them to have. You can then put those variables further down in your config where they'll be evaluated. If you want to change them later, you won't have to hunt for them. You can even insert such variables in place of values in your custom.el file. (If you do this, be mindful when you're inserting the variables that any manual changes to your custom.el file will be overwritten if you save settings from the *Customize interface* before restarting Emacs.) 10. Use `imenu`. By default, it lets you jump to function names and such. But you can change the regular expressions it uses to whatever you want. If you end up using use-package, you can set it up to find any use-package declaration, or you can change it to find your package-block comments. It's a very quick way to jump around... Or if it's too much hassle, you can just use `isearch` to find your package blocks. No shame in that either. EDIT: fix reference to "helpful" function in number 6.

I used an org-mode init file, but it did not help at all, so I went back to 1 init.el file. What did help was getting rid of `customize`, switching the package manager to straight, and using a lot of `use-package` sexps to keep things organized. I also sorted through an old college config a while ago, I don't think there's any way around being a bit bewildered. What's good is that a lot of my old code became unnecessary due to emacs/package improvements, maybe just merge your old code as you need it.

Use `use-package`. Keep everything related to a package contained, that is the answer. After declaring the package, tthn the question is, when to load the package? 1. after a command? bind a key to the command or use the `:commands` keyword. 2. after a major mode? use a `:hook`. 3. after another package? use `:after` I like 1 singe `init.el` file and I use navigation packages such as `consult-outline` to move around package. I also sometimes collapse the use-package declarations with `outline-minor-mode`. If a package declaration gets big, I can separate into two or three. I do this for my `org` config.

i first started using Emacs around '97/'98, and have basically been using it continuously since then - i not only use it for writing code and documentation, but also as my email client, a Gemini browser, a file system UI (`dired`), a bookmarks manager (`Ebuku`) etc. - so my Emacs config has grown (and continues to grow) organically. Although i'm not constantly tinkering with it, i *am* regularly interacting with it e.g. just today i added config for the `highlight-indent-guides-mode` package. And occasionally i do a 'code review', where i do things like remove stuff i no longer use, or refactor. A number of years ago i moved to an Org-based config which i tangle, but not for 'literate programming' purposes. Instead, i do so to create a configuration hierarchy for grouping and hiding/showing. So the top level of my config.org file looks like: * Config ** Initial setup... ** Variables... ** Bindings... ** Extensions... ** Post-init configuration... And if i expand the "Extensions" section, for example, i have: ** Extensions *** Apps *** TeX *** Utilities *** Games *** Miscellaneous extensions [etc.] My config file is under version control (Git). i run stock Emacs, rather than a distro, and haven't felt any need to redo my 3300+-line config to utilise `use-package`. i also use the built-in package manager, with 200+ packages installed; there have been occasions it would have been helpful if i was using e.g. `straight.el`, but generally i find i don't need it.

I would also add move the package specific confifuration if your init.el file grows too big for you to be comfortable

Don't use `use-package`. Okay, okay... not really :) Just don't *only* use use-package and force your thinking into it's way of organization. Funnily enough I've been procrastinating writing [Finding the best style of literate emacs configuration](https://www.paretooptimal.dev/finding-the-best-style-of-literate-emacs-configuration/) but your request and remembering this exact struggle pushed me to get something useful up. In short? use-package alone isn't the only way of organizing code literately, consider organizing by your use case such as: * my use-cases ** version control with git ** Haskell development because it scales better than: * use-package ** magit ** haskell-mode See my earlier link for a longer example and maybe some more exploration in the future.

This. If you do (setq use-package-enable-imenu-support t) then `imenu` finds `use-package` forms and that is all the nav I need.

If you wrote it, and organised it in a way that makes sense to you, then you're less likely to be bewildered by it later. If you copy and pasted someone else's suggested approach to a config, and then shoehorned your own stuff in there somewhere, and carried on with your day, you'll probably forget it all. You can still copy a suggested approach which seems logical to you -- but take the time to really understand it. Do that and you should be fine.

use-package can accommodate either style of organization.

I agree. I actually use both, I just re-read my comment can see how it would imply otherwise. I'll have to rewrite it a bit.

`consult-outline` is great for hopping around .emacs if I know where I want to go. I also achieve the nice hierarchy of an org init file *without* the tangling by using comment headers with `outshine`, an embellishment of outline mode which uses sensible org-like keybinding. Add nested header comment lines like: ;;; Packages... ;;;; Theme and Style... ;;;;; moody - simple modeline decorator... and it's pretty easy to navigate.

> do `(setq custom-file "custom.el")` and at the bottom of your file, put `(load custom-file)`. > Then, use the Customization interface for everything that allows it. +1.