> And you will never again pull your hair out because some editor swapped a tab for four spaces and made Make do insane things.
steps up to you and whispers in your ear
Or you could, you know... use a real text editor.
steps up to you and whispers in your ear
Or you could, you know... use a real text editor.
I have been working with Makefile’s, with a team, for close to ten years and have never encountered anyone accidentally using spaces. I guess someone editing it via GitHubs web ui or something.
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 real solution is to not have your editor silently convert tabs to spaces, ever.
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.
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
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 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.
IMO, since Makefile has only one-level indentation for commands, this use of significant whitespace is rather benign, compared to Python.
Yes, you can see this in the make filetype plugin in Vim’s $VIMRUNTIME directory, which is usually
/usr/share/vim/vim81
$VIMRUNTIME/ftplugin/make.vim.
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.
Auto-detecting tabs/spaces sounds like magic, which not everyone likes.
It is your responsibility to let editors know that, be adding that magical first line to your make.
But you notice your mistake very quickly and I've never sent code to code review with spaces instead of tabs.
So, I configured my syntax highlighting to very subtly show whitespace characters. The editor keeps them consistent in every other case. Have never had the problem again since.