Somewhen down the line, my tab-width accidentally got set to 2.
That meant that indent-region in Lisp code inserted a ton of extra tabs.
And when I pasted that code into other formats, like Markdown, it’d look weird so I’d run untabify on it.
I didn’t know what was going on but when I finally got around to finding the issue and fixing it, I was really surprised.
I set the tab-width back to the default (which is 8) and reverted the lisp buffers. They suddenly looked massively borked. Even though I had run indent-region on them earlier!
And then when I re-ran indent-region, it started looking normal again.
In other words: the tab-width has zero bearing on how lisp code looks in Emacs.
I’ve been programming since 1993 and never cared about the tabs vs spaces debate. I like a two-column indentation offset, or even one is fine, and eigth is a li’l too wide for my taste, but that’s technically a preference not directly tied to whether or not a file should be encoded with tabs or with spaces. If it’s with spaces, everyone sees the same, if it’s with tabs, everyne sees according to their setting, both those have merit. I’m OK either way and use dtrt-indent so that code I check in will match its surroundings.
People who are fans of using tabs use the argument that tabs make it so that everyone can have the code looking the way they want to.
But that’s not what scheme mode was doing. It indented to the same fixed columns no matter what the tab size was, and only used tabs as some sorta cheap file compression engine. “Oooh I can replace 8 spaces with one byte!”
Conclusion: scheme-mode doesn’t deserve to use tabs. It lost that privilege.
(add-hook 'scheme-mode-hook
(lambda ()
(setq-local indent-tabs-mode nil)))