@drq @jbz my "init.el" is always evolving, but I have not had to start over in many years now.

- Keep global configurations at the top, for example to disable menu bar and toolbar.
- Setup package sources below global config, this controls how "use-package" works, especially if you use the ":ensure t" keyword.
- Next set the "custom-file" variable, make sure variables set by the "customize" program are in a separate file.
- Personalized key bindings that do not rely on external packages come next.
- I use revision control to copy my config across multiple machines, I keep each machine-specific config in separate files and "load" the relevant config by inspecting the "system-name" global variable.
- Use "use-package" to configure mode-specific settings. I like to keep packages I install just to try them out for a bit toward the bottom of "init.el" and clean these up every so often.
- Macros you wrote yourself, or copy-pasted from the Internet should go in a separate file that you "load" toward the bottom of "init.el".
- Avoid literate config, just write comments on anything that isn't obvious.

Basically, the idea is to keep configuration variables that work everywhere across all Emacsen at the top of the file, and gradually write more specific configuration toward the bottom. Code that is most likely to work correctly goes toward the top, code that is likely to err goes toward the bottom. Using these guidelines, I only ever need to make tiny tweaks to the "init.el" file, and it evolves in a way that is easy to manage.

#emacs #EmacsConfiguration #EmacsBankruptcy