The problem isn’t so much the difficulty in finding a pre-made config, it’s a combination of:

A) which premade config to choose

B) what half of those settings even do (and do you need them)

C) a lack of “sane” defaults that use the built in abilities

Realistically walking through the article authors “emacs from scratch” config and seeing what can be done with the built in packages and how is hugely instructive but even then you only get that from walking through the config one line at a time and reading “help” documentation for most of it.

At this point emacs is so old that fixing the problem of “sane defaults” is probably near impossible if only for how much it would break existing configs. But it might be a good addition to the tutorial to provide a set of questions and answers (possibly with demonstrations) that allow a new user to generate their own config with some nice defaults. We can assume these days that most new emacs users are coming from some other editors, so asking questions like “do you want auto complete suggestions in an inline drop down like VSCode” could be a perfectly reasonable question and then it could add the correct configuration settings to config for you using just the built in functionality

>if that were to be built on, who would decide what gets put in?

A small number of people with taste and experience.

Like one hopes to be the case for every opinionated preset profile set.

Both of those are modal editor configs. Which... No thanks?

Oh yes. What other software allows you so much to make it your own? Yes, I know the yak shaving argument etc. But what's the fun in opening up some computer/OS/software that looks and feels exactly like everyone elses? An Emacs (and vim) setup is something you can actually have a discussion about with someone else.

And then slowly over 20 or so years deleting all of it.

I think I'm down to about 110 lines of ~/.vimrc now :}

Tell your agent what parts of Doom Emacs you actually use, and ask it to build a minimal init.el containing only those parts. You're probably only using ~2% of Doom, so the resulting init.el will likely only be a few hundred lines, and most of those lines will be comments and key bindings.

It won't be a perfect transition, but it will make it a lot smoother.

I'm also a Doom user, albeit a new one. What is making you consider the switch?

It is fairly trivial to make something 'like it', but what people advocating for this stuff want is for it to be shipped with regular plain old normal GNU Emacs so they can set it up quickly and easily in an Emacs installation on a work laptop (and it may make it easier to convert people to Emacs for those who care about that).

I spent a lot of time making my own elisp config for a custom emacs experience and ended up getting something similar to Doom Emacs. So, I just switched to use Doom :)

Yeah, it'd be easy, but the hard part is getting people to agree what the standard will be.

Plus, frankly, a lot of people (myself included) who want a richer experience are pretty much just happy turning on emacs keybindings in VSCode or IntelliJ or whatever.

For your consideration, two Elisp packages I've written that focus on feature discoverability and use: Casual and Anju, both available from MELPA. You can read more about them at the following links: https://github.com/kickingvegas/casual https://github.com/kickingvegas/anju

treesitter (with easily installable grammars - a big pain point) / LSP integration OOTB / themability

Plus now agent integration (aka GPTEL)

Vertico feels like a must-have to me these days. I also like to have treemacs installed.

Apart from that, I don't have a lot I insist on, and my used emacs package space keeps shrinking.

That said lately I use lem more than I do GNU emacs.

IDEs exist to allow teams or entire divisions to hit the ground running with development, with a standard interface that everybody on the same team uses (a huge boon for collaboration), without a lot of time spent configuring or integrating the tools. All the integration is done by the vendor, often better than you can do it; the debugger integration in full-fat Visual Studio is still second to none.

Grooming a personal .emacs or .vimrc is fine if you're working alone, but when you're on a team of professionals working on an application built on a commercial platform, a standard workflow for development is essential and an IDE supplies all the tools, integrations, and conventions to cover the basics of such a standard. Do not underestimate their value.