[jolmg]

> Inconsistent indentation is NOT a problem in practice. inconsistent tab/space use is a problem in practice

Alright, I was talking about the latter, which causes the former when you're not evaluating file modelines.

> not a "wide" one in my experience

I have a ~/build directory that contains source files of 207 projects whose source I've downloaded over the years for various reasons. Of those 207, if I look for mixes of tabs and spaces in indentations using:

  for p in ~/build/{pkg,repo}/*; do
    grep -IPlr '^\s*( \t|\t )' $p/^.git | head -1
  done | wc -l

I get 144. You may consider the pattern `\t ` ok though because some people think it's cool to use tabs for indentation and spaces for alignment, but if I exclude those:

  for p in ~/build/{pkg,repo}/*; do
    grep -IPlr '^\s* \t' $p/^.git | head -1      
  done | wc -l

I still get 110. Now, those are just the ones that have a space and then a tab in one indentation. How about those that use a space as the first character in one indentation and then a tab as an adjacent line's first character in its indentation?

  for p in ~/build/{pkg,repo}/*; do
    ag -lr '^ .*\n\t|^\t.*\n |^\s* \t' $p/^.git | head -1 
  done | wc -l                       

That's 142.

If I run that last one only against pkg/, which contains mostly official package sources of my distro, then I get 69 matches out of 89 packages.

Note these are not file counts, but project counts with at least one such file.

You may view this as using a small sample size, but at least, the practice is pretty wide in my experience.

[jolmg]

I forgot to mention:

> but if you use the right tab width (and many projects mark it inside the files with a hint e.g. Emacs understands so that won't be an issue) - then it becomes a non problem too.

This isn't going to work when you're looking at a diff/patch, emailing an excerpt or otherwise looking at the code outside of a particular editor.