Happened to me just the other day.

I added a makefile to a project that didn't yet have one, and I didn't have makefile support added in my IDE.

Got some weird, unhelpful errors when trying to run make, and eventually realised spaces were being used instead of tabs.

The solution was to configure my .editorconfig file to use tabs for makefiles, and as a nice-to-have, to also install a makefile plugin in my IDE.

> The solution was to configure my .editorconfig file to use tabs for makefiles

The real solution is to not have your editor silently convert tabs to spaces, ever.

The real solution for dealing with spaces vs tabs is that there's no real solution that will work all the time. Or maybe we could go back in time and murder both hitler and the person who decided that tabs should be a separate character (which I wouldn't be surprised if they were the same person).

If you don't autoconvert you risk ending up with a file mixing tabs and spaces which can range from a mild annoyance to generating very perplexing errors that are a pain to debug if the file's format is sensitive to indentation (such as python scripts or... Makefiles). I suppose you could argue that the conversion should require user interaction but frankly that sounds like a hassle since 99% of the time autoconverting is absolutely fine.

Furthermore it makes total sense to use an editor config to force a certain standard and avoid problems in the future, especially if you work with many third party libraries with different coding styles. At work I deal with python files indented with 4 spaces, the Linux kernel indented indented with 8-space tabs and a bunch of other projects and language who may or may not be using other variants. You'll have to pry my editorconfigs from my cold, dead hands.

> Or maybe we could go back in time and murder both hitler and the person who decided that tabs should be a separate character (which I wouldn't be surprised if they were the same person).

You got the timeline almost right. A tab and a space are not only different characters, they are not even in the same category of characters.

A space is a whitespace character whereas a tab is a control character that moves the cursor to a specific position. Its name is an indicator for what it was used in the beginning, to arrange data in a tabular form.

The real problem is that many editors don't show tabs differently from spaces. In vim you can do a lot with the options "listchars".

My settings there are: set list listchars=tab:>-,eol:$,nbsp:~,trail:X

> Or maybe we could go back in time and murder both hitler and the person who decided that tabs should be a separate character (which I wouldn't be surprised if they were the same person).

Tab released the spring holding the carriage in place and let it slide backwards until a tab on the base his a tab on the carriage that prevented it moving further on its own. High tech typewriters let you adjust the position of these tab stops (or "stop tabs", if you prefer). This back from the days when many typewriters omitted "1" and "0" -- we just typed l and O.

Tab on the oldest printing terminals simply had this behavior as they were essentially complicated typewriters anyway ("TTY" is "Tele TYpewriter")

BTW your post does not invoke Godwin's law.

I have to say, I long favoured tabs myself - but I eventually gave up and decided not to die on that hill.

Any editor from the last twenty years should know to indent a Makefile with tabs.

Well, we could pretend that's the case, or we could accept the reality - many don't, at least not out of the box.

I've copied lines from a shell script into a makefile and it copied the leading spaces as well. I didn't really think about it and when I ran make I got a bunch of weird errors. I figured out what the problem was pretty much immediately. Overall this was just a minor annoyance for a minute or two, but it does happen. I'm not sure why people pretend that it doesn't.

I don't work with make much anymore (or Python or Haskell), but I've come to see the use of invisible characters to express structure as a mistake. It can make code real neat and tidy looking, but I'm not sure the trade off is worth it. In the past I've resorted to actually having my editor show whitespace symbols to make sure code that looks aligned actually is aligned.

There is nothing that prohibited the original author of Make from allowing any whitespace as a command prefix. The fact that it does not do so is a historical accident, and a mistake admitted by its creator. Such a change would simply make everyone's life easier.

IMO, since Makefile has only one-level indentation for commands, this use of significant whitespace is rather benign, compared to Python.

I ":set expandtab" in vim by default, I don't like mixing tabs and spaces. People have different opinions on this, I get it. So when I pop on over to the Makefile buffer, I have to remember to either ":set noexpandtab" or to copy a previous target down and edit it directly. Now I'll just swap out ">" instead of using tabs, which will make things simpler.

I have the same setting, but vim automatically sets `noexpandtab` when editing a file named Makefile. I don't have any explicit setting to do that, nor any Makefile-related plugin.

>I have the same setting, but vim automatically sets `noexpandtab` when editing a file named Makefile.

Yes, you can see this in the make filetype plugin in Vim’s $VIMRUNTIME directory, which is usually

    /usr/share/vim/vim81

which contains all of the plugins, syntax definition files, etc. that come with Vim. The file for make is located at

    $VIMRUNTIME/ftplugin/make.vim.

It’s pretty straight forward to override any default behavior you’d like to change; this is a great article on how all of this works [1].

[1]: https://vimways.org/2018/from-vimrc-to-vim/

That's interesting, I didn't know that. I think I might be shooting myself in the foot by saving a session and doing "vim -S" to load it again with expandtab set or something. I load multiple buffers associated with a project and use :b to move from file to file. I know it expands the tab when I move to the Makefile buffer, because I have to kick myself and remember to set noexpandtab when it inevitably puts in spaces. Or maybe putting expandtab in my .vimrc overrides the normal behavior.

I think you need to need to `filetype indent on` and/or `filetype plugin on` in your vimrc.

I can give an example.

Recently I was working on a project with multiple Makefiles, ie Makefile.{win,nix}. My Emacs config did not load makefile-mode due to the suffixes. As spaces are my default, I got spaces on TAB, iirc even after turning on makefile-mode.

Shouldn't you configure emacs to auto-detect tabs/spaces on the file you've opened?

Whoever is responsible should rename the files so their names end with ".mk" or ".make", the standard extensions that Emacs and other editors recognize.

Auto-detecting tabs/spaces sounds like magic, which not everyone likes.

Of course emacs did not "detect" your non-standard makefile.

It is your responsibility to let editors know that, be adding that magical first line to your make.

Not sure who you're responding to. I don't blame anything here, just illustrate what might cause confusion of tabs and spaces in Makefiles, namely unexpected filename suffixes. Holds true for other editors besides Emacs obviously.

I've done it, thanks to using terminal copy/paste (either my actual clipboard, or GNU screen's copy buffer) instead of my editor's built-in copy/paste. Sometimes it's because I'm viewing a patch in a web UI or `git show` and pasting a few lines from it into my text editor.

But you notice your mistake very quickly and I've never sent code to code review with spaces instead of tabs.