That seems like a terrible idea. You change the basic syntax of the entire Makefile, forcing anybody reading it to get used to your custom indentation, where almost every line starts with an unnecessary >.
Are you going to fix everyone else’s editor too? Software is a multiplayer game and eliminating a whole class of error that hinges on someone not noticing the difference between invisible characters in a diff is a huge win.
I'm not 100% certain, but I suspect a Makefile with this error will become unusable. So, no need to fix their editor, they will fix it themselves after their builds fail.
Are there any major editors that can't handle this? Given that python has a very similar kind of formatting I would assume any editor that a programmer is using today can handle it.
In Python, if you save your file with tabs as spaces, the code 1) still works, and 2) does the same thing it did before. Furthermore, it prohibits mixing tabs and spaces up in the same file, on the basis that it's impossible to reliably determine indentation levels then. So this isn't really a major issue with Python, unlike Make.
Sure, I'm happy to agree that the original design of make is kind of questionable. My point was that an editor which can handle telling you to not mix tabs and spaces in python should also be able to tell you to use tabs in a Makefile. Or, if you prefer, that if python can say "only tabs xor spaces" and be seen as reasonable, then make can say "only tabs" and be equally reasonable.
The editor doesn't need to do anything special to avoid mixing tabs and spaces in Python - quite the opposite, the simplest editors (the ones that either preserve or expand all tabs when you save, depending on the setting) will do.
Just about everyone I know uses VSCode, which handles Makefiles correctly out of the box, or I can trust to have a correct vim config, so honestly I think I'm okay with it. If something breaks, it'll break loud.
There's a lot of other really good advice in this article but this one feels unfounded.
And this isn't some obscure thing that people need to have got around to configuring; vim works properly with Makefiles (marking non-tab leading whitespace as an error) out of the box on at least Ubuntu and I'd guess much more widely than that (all distros and Mac and Windows and also when building from source wouldn't surprise me, although it also wouldn't surprise me if there were a couple of exceptions where things would need to be massaged).
Yeah, the two places I find myself still reaching for vim are Git commits and quick shell/Makefile tweaks and both are correctly formatted out of the box (shortened Git first lines on commits, etc).
That seems like a terrible idea. You change the basic syntax of the entire Makefile, forcing anybody reading it to get used to your custom indentation, where almost every line starts with an unnecessary >.