4 ms·

> Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don'

> Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. 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.

dilap 4y ago
For sure. But I think what's going wrong is a little different. 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.)