@bozhidar I wanted to use use-package, so instead of prelude I copied and modified your personal config!

I was waiting for it to become more mainstream/mature before leveraging it out-of-the-box, but this is bound to happen at some point.

The challenge I've always had with Emacs, which is also present in VS Code and Atom, is the simultaneous key presses required for keybindings, e.g. C-x M-j I found them very slow as a touch typist and would take longer to build up muscle memory. When I switched to Evil and the Spacemacs mnemonic keybinding approach, it turned Emacs into an editor that I found highly productive and simple to learn and use. Doom also has great evil support, but I find the keybinding choices a little strange. The great thing is that there is lots of choices for having Emacs in a way that's best for yourself and it seems we are long past saying everyone should build their own Emacs init.el.

use-package is nice, but imho it has to be paired with straight.el to be decent with guaranteed reproducibility. Otherwise you're still at the mercy of upstream packages changes (outside of melpa-stable, which is only 1 version per package)

it's a common theme, I think even the author of use-package (who's emacs maintainer) pins down package/lib versions via nix in his case. Straight achieves the same without having to go into nix.

love that phrase "without having to go into nix" - i spent a lot of time with nix...waiting for things to compile :) i love nix and guix too, but don't have the time!

nix is awesome, but personally I want to have emacs stuff just be inside my emacs config and not spread at nix level

his setup is also pre-straight-el, I suspect he might have used straight otherwise

makes sense on both accounts.

@jr0cket Yes much of this is a matter of personal taste. With all the time in the world I'd start from an empty init.el and go from there, but that's just a preference without any real reason behind it. And I'm not even consistent with that - for example, I've long enjoyed using the IntelliJ IDE family, and in that case I have little knowledge of what's under the hood.