> Alignment is desired because it enhances readability.

While that's true I was asking specifically about those examples of yours. What would be the reason to have a weird L shaped comment around the code like that? Right now I can only see two situations in which something is aligned in code, the first one being something like this

    int    foo;
    double a;

because for some reason people like to have variables like that. Personally I don't see why anyone would want to do that but if they want to insert extra spaces they can do that, it's trivial to clang format before the commit and absolutely nobody even has the idea of using tabs there.

The second one are function arguments over multiple lines. Personally again I find it a bit ridiculous that someone absolutely needs to have

  void foo(arg, arg
           arg, arg)
  {
      ...
  }

when

  void foo(
      arg, arg, 
      arg, arg)
  {
      ...
  }

is just as readable and even saves you keystrokes because you can use an indent level for the alignment of the arguments and just have one tab (well two, since it's two lines) there instead of the 9 spaces you otherwise need. But again if they prefer the other style then that's fine, but it's no reason to force them to do the indentation with spaces too. Your example is flawed, you should never mix tabs and spaces like that, tabs never follow spaces. You use tabs to indent to whatever level you're currently on and then if you really want that alignment for whatever reasons you use spaces for the rest.

> Enforcing it will just be a big waste of time, compared to the simplicity of banishing tabs.

I don't think a clang format commit hook is that hard to enforce. Not to mention that you are enforcing formatting anyway, otherwise you end up with one person using 2 spaces and the other 8. And if you already enforce that then there is no reason to not just enforce using tabs for indentation since they are objectively superior.

> People who suffer from an indentation width they don't like have a psychological problem that perhaps makes them unsuitable for this line of work. The professional developer can happily work with any indentation format and maintain it as-is.

> The only halfway valid argument here is regarding people with severe visual disabilities. Everything else is whiny primadonna fluff.

Do you really think that dismissing people's preferences as psychological disorders is a good idea? Especially in a community that likes to customize the shit out of everything? Why shouldn't they be allowed to see the code however they like? That's literally the idea of using tabs, you can see them as 37 spaces if you like but for me it's 4. If you want to do any extra alignment after the indentation then use spaces, sure. But who are you to decide how far right on my screen the body of the loop appears? Tbh if you ask me I find your proposal straightup draconic, you rather ban tabs completely rather than using the available tooling and/or properly training your people to enable everyone to work as they see fit. Yeah sure most people can work with a 8 spaces codebase if forced to but that doesn't mean it's a good idea.

And since you brought up disabilities: I've worked with someone who had only one eye, he didn't do any indentation because otherwise he'd have to constantly move his head around. Set tabwidth to 0 in his editor and you don't need to do any reformatting on commits if you indent using tabs. Force spaces on everyone and he needs to do a reformat all the time.

> (I don't think my editor can do this and don't know of any which can).

I'm not sure I follow why this is necessary. They already act like that, the only tabs not being as wide as X spaces are the ones that follow a non-tab character and at that point you are no longer doing indentation anyway so a tab should not even exist there. Though I don't see a reason to not have this, should be a simple setting in any editor.