This test uses an indentation of 4 spaces and tab width of 8. We can't support this anymore but I think that's fine.

It seems reasonable though hopefully we're not overlooking some valid usage. This is all inferred, right, so there's no way to GitHub Code Search to find users that might rely on this?

Editorconfig doesn't support different visual width for tabs and indent. And I think that makes sense. You don't need a tab-width setting if you don't use tabs.

This particular test case applies only to unformatted code where black assumes a tab size of 8 for tabs in docstrings before normalizing the docstring indentation. This is only a heuristic and I think it probably works best anyway if the space indentation and tab indentation sizes match, because that's probably how you aligned your docstring before even if you happened to have mixed tabs and spaces.

These tests were off, probably because we now use best fitting for strings now. I verified manually that they don't exceed the line width for the configured indent width.

It seems reasonable though hopefully we're not overlooking some valid usage. This is all inferred, right, so there's no way to GitHub Code Search to find users that might rely on this?

Both black and cpython itself have this hardcoded to 8, e.g.

print(inspect.cleandoc('''
def a():
    """doc line 1
    doc line 2
\tdoc line 3
    """
'''))

expands to

def a():
    """doc line 1
    doc line 2
        doc line 3
    """

Given that this is a cpython choice, i don't think we should have an option to overwrite it.

Thanks for bringing this up. I wasn't aware of this (although this PR doesn't change the configurable nature of tab width).

I think the reason why Black hardcoded this is simply because black doesn't support tab indentation and choosing the default tab size used by cpython seems a good choice.

Picking the configured indent-width still seems reasonable to me, except we foresee issues when using indent-style: tab with any tab-width value other than 8. For example, does it mean that the output of inspect.cleancode has incorrect indentation or is it okay for as long as all code uses tabs?

I've tested the semantics:

source = '''
class A:
\tdef a():
\t\t"""doc line 1
\t\tdoc line 2
\t\t  doc line 3
\t\t"""

def a():
\t"""doc line 1
\tdoc line 2
\t  doc line 3
\t"""

class A2:
\tdef a():
\t\t"""doc line 1
\t\t\tdoc line 2
\t\t  doc line 3
\t\t"""

def a2():
\t"""doc line 1
\t\tdoc line 2
\t  doc line 3
\t"""
'''
exec(source)
docs = [A.a.__doc__, a.__doc__, A2.a.__doc__, a2.__doc__]
for doc in docs:
    print(f"---\n{inspect.cleandoc(doc)}")

prints

---
doc line 1
doc line 2
  doc line 3
---
doc line 1
doc line 2
  doc line 3
---
doc line 1
      doc line 2
doc line 3
---
doc line 1
      doc line 2
doc line 3

I've also checked that

source2 = '''
def f():
 \tprint()
 \tprint()

def f():
              \t          \t     print()
              \t          \t     print()
'''
exec(source2)

passes. Python seems to not care about how you mix tabs and spaces as long as you're consistent.

Inside of docstrings, cleandoc doesn't mind inconsistent indentation and will just pad to multiples of 8:

source2 = '''
class A:
\tdef a():
\t\t"""doc line 1
 \t    \t doc line 2
\t \t  doc line 3
\t\t"""
'''
exec(source2)
print(f"---\n{inspect.cleandoc(A.a.__doc__)}")

My suggestion would be to special case count_indentation_like_black by hard code padding to 8 and converting to spaces in docstrings.

Thanks for taking a closer look at this. I updated the PR to hardcode 8 for the normalization.