I'm addicted to the flexibility, but I dream of something that offers the same level of flexibility in a more robust ecosystem (e.g. statically typed, statically scoped, what else?). (Is such a thing even possible? I don't know!)
Speak for yourself. Just last weekend I had a few hours with little to do, and actually wanted to do some yak shaving on my Emacs config just for the hell of it. but it works too well and I have everything the way I like it! My yak is f*kin' bald, man!
Not only have I already worked out all the little bugs that annoy me, but I've added all the features I can think of that I want!
Here's my list of problems to solve on a rainy day†:
;; * kill-word-sp cancels ioccur mode for some reason
;; * after running ipython for a while, all terminal commands hang waiting for output
;; * iedit substition starts just corrupting shit (e.g., try replacing \t with spaces)
;; * "replace-match-maybe-edit: Match data clobbered by buffer modification hooks"
;; * delete-horizontal-space doesn't work w/ iedit mode
;; * vc-annotate doesn't properly restore window configuration
;; * the popup used by dumb-jump breaks when line wrapping is enabled and it's used on a wrapped line
;; * sometimes trying to launch a new shell just kills the old shell
;; * godef doesn't work when narrowed
;; * emacs stopped automatically recompiling .emacs wtf
;; * grep-ed while buffer is in loccur mode fucks things up
;; * undo in loccur mode messes things up
;; * visual-line-mode jumps around on very long lines (like paragraph long)
;; * parens don't overwrite properly in go-mode
;; * «Error running timer `auto-revert-buffers': (wrong-type-argument number-or-marker-p nil)»
;; * shell doesn't save history a lot of the time
;; * piece of shit grep edit silently fails on spaces on file names
;; * code-wrap is stupid with long separator lines (like "//---" for a long time)
;; - sadly might be a visual line mode bug, actually...
;; * line highlight doesn't work after jumping to a definition
;; * highlight line mode doesn't work on most recent line in shell
;; * tendency to identify buffers by name causes bugs when renaming buffers ("stringly typed")
;; * subword mode doesn't think DEBUG_MEGA_GOLD is three words (in a .go file)
;; * if a shell command tries to open a file in emacs, and the active window is the minibuffer, the file will open into the minibuffer
Probably the biggest source of issues is two different modes not playing well with each other, which is understandable, but also something it feels like a less freeform approach to an editor might reasonably be able to do a better job of avoiding.† To be fair, not all bugs -- some are just configuration issues I haven't figured out yet.
Change to follow XDG specification and ~/.config/emacs having precedence?
It's been a while since I wrote that note to myself, but I somehow had .emacs setup so it'd get recompiled automatically to byte code on changes (which helps startup speed), and somehow whatever I setup at some point stopped working. (Which resulted in my .emacs changes being silently ignored, as stale .elc was used -- that was confusing to figure out!)
For now I just gave up and stopped using the byte-compiled version, sometimes life is too short, even for an emacs user!
(Though in general anyone who chooses to use emacs must not think life is TOO short...)
There's no difference between an advanced emacs config and a software project.
If you don't test or incubate features long enough before your workflow depends on them you'll find yourself building atop more bugs.
I find tagging releases of my emacs config useful for this.
E.g., there's a mode that highlights the current line. And there's a mode that let's you run a shell inside a buffer.
And for some reason, the current line highlight doesn't work on the most-recent (waiting for input) line.
OK, actually looking at this a little more closely, I think it's because shell mode does some sort of thing where it redefines the "start" of the line to not include the shell prompt, and I guess whatever is doing the line highlighting is using that same notion of "start" of line. So on a line that just contains the prompt, the line highlighter thinks the line is zero length, and highlights nothing.
I think this is typical of lots of emacs problems. You have all these modes that interact w/ each other, w/o strong models of the interactions, so you end up with a bunch of little bugs.
(And because there's combinatorially many different ways you can combine modes, I don't think testing is ever really going to help you here. You just need formal structures and coding styles that guarantee or lend themselves more to correctness.)
> There's a lot of cargo culted config fragments like the ones you'll find in the article.
Besides changing the gc-cons-threshold (which is indeed a questionable fragment to blindly copy/paste), there were no other specific config fragments, only examples. People blindly paste config fragments for everything (e.g. set nocompatible in Vim).
> Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs?
What is there to reinvent? It should take almost no extra configuration to properly defer package loading. Package loading is also not automatic. If you are explicitly loading every package you've installed during init, that's your fault. You shouldn't blindly copy things into your config. If you really don't want to handle configuration yourself, starter kits exist for a reason.
> In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. If Emacs is that fragile, then its extensibility is really a moot point.
It is mostly a user problem. Emacs lets you do anything. It gives you enough rope to hang yourself with. I could write an unreadable and broken mess of a program in any programming language, but that doesn't say anything about whether a language is fundamentally flawed.
It's a double-edged sword. There's no such thing as bug-free software. And the more functionality, the more room for misconfiguration and bugs. Vim/neovim come nowhere close in terms of functionality. The correct word isn't "fragile." A better word would be "malleable." It's the editable editor. Emacs' malleability is at least part of the reason why it's able to stay relevant despite the fact that it has very few developers compared to Vim and other editors. Because Emacs is this way, it's potentially easier to do something dumb or install a bunch of useless, slow packages, but because Emacs is this way we also have Magit, org-mode, and a bunch of other killer packages that Vim has much worse versions of (or no equivalent of at all).
This means that if you only need a simple setup, Emacs is not that appealing, but my experience has been that I have no idea what I want until I know what is actually possible (e.g. I didn't grok magit until I read the entire manual and saw how greatly it would simplify my workflow).