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
A small number of people with taste and experience.
Like one hopes to be the case for every opinionated preset profile set.
I think I'm down to about 110 lines of ~/.vimrc now :}
The core editing components of non-Evil emacs are direct manipulation, not modal. That there are modal aspects on top of that for doing things which practically/genuinely need a modal switch (command entry, search entry, etc) doesn't make the default emacs configuration a "modal editor" in any sense of which people actually apply those terms.
By your definition of modal, almost every application can be described this way. The point is not whether a system has modes, it's whether it makes its core emphasis and interaction modal.
You can see vi's motions as elegant and purposeful. I see them as an accident of history stemming from the poverty of the number of keys and capabilities of the dumb terminal it was designed on.
I encountered both editors in the late 80s and chose emacs precisely because it didn't have the "barely a step up from a teletype" interaction model that vi had.
As for Doom and Spacemacs without Evil.. yes... but why? Their original and state purpose was a packaging with a modal default. It's trivial to toss together your own init.el that brings in the same set of packages these days and with very little effort.
If the goal is an easy packaging of emacs with sensible defaults.. and then you have to go modify the defaults to make it what most people (yes, most) would consider sensible... No, that's not meeting the state use case.
Sure I do, and there's so much tacit knowledge that I can't ever explain verbally or in writing that goes into it, to the point that arguments like yours, challenging my "choices" would ever feel less disingenuous. It's like forcing a left-handed kid to hold the pen "correctly", due to religious dogmas. It just works far more naturally for me and thousands of other people, and just because you don't get it, it doesn't make the model useless. Try to see the other side, sometimes "dumb" ideas do work, and shit that works maybe ain't that stupid.
> Doom and Spacemacs without Evil.. yes... but why
Great question. Now maybe you're trying to learn something despite of "years of the opposite experience" feeding to your hubris. Doom offers a set of Lisp macros that come very handy - map!, add-hook!, defadvice!, undefadvice!, add-transient-hook!, etc. - they genuinely can slash the inevitable boilerplate in the config. It's much easier to experiment with advising and instead then writing ad-remove-advice with different syntax, repeating the symbol names, etc., you'd simply prepend `un` to the form and eval it. add-hook! allows binding multiple fns to multiple hooks. And these are just some examples.
Also Doom does some tricks to make the startup blazing fast. Many times I have compared my config (that pulls over 350 packages) with someone else's vanilla. Doom demonstrably starts much faster.
It won't be a perfect transition, but it will make it a lot smoother.
The bigger thing. "Ask the agent to build it" is fine here because init.el is read-only damage. Worst case it writes a file you `git diff` before trusting. That's the safe end of the spectrum. The instinct breaks the moment the same agent is touching things you can't cheaply inspect: package installs, shell-outs in a hook, anything with a side effect off your disk.
The lesson I keep relearning building this stuff: an audit log after the fact tells you what broke, it doesn't stop it. What you actually want is a capability check before the agent acts. This run is allowed to write `~/.config`, not to curl-pipe-sh. Plus a trail you can't quietly rewrite later, a hash chain, not a log file anyone with write access can edit. For an init.el that's overkill. For an agent you'd let near `apt` or your dotfiles repo, it's the whole game.
Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.
> I don't fully understand the editor
Going vanilla will not help you there - well, not completely anyway. Moreover, it may even obscure some features that were easily accesible before.
> I don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature
That is not very difficult - learn how to use built-in features - profiler, edebug, describe-, apropos-, hooks and advising, etc.; Start writing Elisp code (with understanding it). In the end, it won't really matter - whatever runs in your Emacs, there's always a way to get to the source. And if you ever need to disable any feature of Doom - there are multiple ways to do that.
I imagine it would take a lot of time, maybe. Any greybeards that do this?
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.
I have cua-mode and don't show startup message. What else do I need to modernize Emacs?
Plus now agent integration (aka GPTEL)
`treesitter` grammars _are_ easy to install.
`eglot` is available OOTB, `lsp-mode` is easy to install and configure if you prefer.
`gptel` is easy to install and configure.
I also don't think I'd ever call configuring Emacs "trivial" compared to more modern editors. Matching the out-of-box experience of something like VS Code or Panic Nova requires some work. This isn't really a knock against Emacs, but I think Emacs fans -- myself included -- need to be honest about that. It's quite possible I would have picked up Emacs years earlier if I hadn't been given the impression that it was just super duper easy, especially once you picked a starter pack. It is not, it probably never will be, and I've come to believe that starter packs are actually a bad idea for most new users. If you don't understand just what it is you're putting in your init.el file and why, then if you run into problems, it's going to be way harder to figure out how to fix them.
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.
First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).
VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.
The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.
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.
But they often use subpar components (code editors, file managements, VCS,..). They are tailored to a specific standard and any deviation to that standard result in a lot of pain. So I much prefer documented tooling subset that can be integrated however you want than an IDE.
Also you usually spend more time using a system than learning it. Aiming thing to beginners increase longterm discomfort.