.emacs bankruptcy

My dot Emacs literally has been following me around for something like 40 years and it’s a total mess. How would you start from a clean directory to build a new .emacs.d? What I want: - preserve my idiosyncratic key binding (mostly) and definitely no vi bindings - load org mode and enable source blocks - load auc-Tex - load a fair number of other packages. The major issue I’m looking to fix is dependency management — with my current stuff, there are deprecated and obsolete packages that warm, but tracking them down is a pain. Is there anything that does a better job with dependencies than the default?

I would use https://github.com/doomemacs/doomemacs but with a blank `init.el` file (no modules). Then you can use Doom's package management and your own private modules.

> Doom's package management Doom uses straight.el for package management

Went through a similar exercise some years ago and landed on a use-package solution https://github.com/xenodium/dotsies/tree/main/emacs (see init.el and early-init.el) broken down into related modules https://github.com/xenodium/dotsies/tree/main/emacs/features It’s one of many ways of doing it. Held up so far.

Yeah, though that happens under the hood of its `core-packages` file which has some packaging macros. `straight.el` is not loaded at runtime, but rather for the CLI `doom` command. So while it uses `straight.el`, I think the flavor of its UI is uniquely Doom's.

https://github.com/purcell/emacs.d

You can try `use-package`. Although its dependency system is intentionally simple, it's usually more than good enough. If you want to load only packages when you need them to, then `use-package` is especially good. If anything, it encourages you to organize things inside a `use-package` block. Having said that, if you don't mind loading stuff you use infrequently, then that's definitely quicker and easier. There's a lot to be said for keeping things linear. `use-package` is also capable of dealing with key bindings, mode hooks, etc. --- so it's useful for that also.

I'm a fan of [https://github.com/edvorg/req-package](https://github.com/edvorg/req-package), which provides dependency management on top of `use=package`.

I still can't understand why we need it when there's `:ensure` and `:after`

I would suggest you turn your whole init file into a literate config. I did it several years ago and it's made working on the config so much more enjoyable. - You could put your current config into one long elisp code block, then, bit by bit, create headings for pieces that you want to document and cleanup. - Use use-package as much as possible. - Set up your org init file to tangle into an .el file on save - Later on, work on speeding up the init. Once you have a literate config and use use-package, this becomes easier and oddly fun. Mine has gone from nearly 2 minutes to start up to around three seconds. My two cents.

Organise with outline minor mode. Create headings in elisp and fold it appropriately.

Every few years I delete my config and start fresh. Lately, doing this with `use-package` has led to a config that I can bootstrap with a mostly-empty `.init.el` (by using the `use-package` `ensure` feature). I find `use-package` worth it, but it is just a bit more cognitive overhead than I would ideally like, since it is a complex macro and debugging issues isn't always easy. Getting familiar with `M-x emacs-lisp-macroexpand` helps a lot.

I don't nuke and pave, but I do cut packages pretty aggressively. I think literate config is the way to go for this. When I don't think I use a package or don't remember what a chunk of code does, I don't tangle it but leave it in my config for a month or so to see if I miss it. If I don't see a need to add the code back it gets the axe.