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
† 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.)