I'm really sceptical of the idea of mixing two different invisible characters in the same file, which is why the tabs+spaces idea makes me feel slightly icky. But another option is just not using alignment spaces at all - if you want to align two parameters/statements/etc, you always split them onto their own lines and use indents directly instead of alignment.

In other words, instead of:

    def my_func(self,
                param):

You always do something like:

    def my_func(
        self,
        param,
    ):

I tend to agree that you shouldn't be "aligning" things with spaces anyway. If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred.

However, regarding "mixing two different invisible characters in the same file" - you can, and should, configure your text editor to display tabs in a visually distinct way from spaces. Kate (my favorite) shows them as chevrons. Geany and Notepad++ show them as arrows. Not only does this make it easier to scan vertically along an indentation level, but doing so also makes it glaringly obvious if a pesky space has snuck in, resulting in a jarring misalignment.

> If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred.

While I agree with this in general, I find making the code nicer to read to be more important that avoiding diff pollution. Especially when that diff pollution can be avoided with a simple "ignore whitespace" in most cases.

I get that if I'm truly mixing one and the other, but if I'm consistently using tabs for indentation, I mostly want them to be invisible - I don't want visual noise on every line. I guess if the syntax highlighting makes them subtle enough it could work, but I think that sort of visual distinction only really works if the visually distinct character only rarely shows up.

I tend to prefer the former, but it suffers from the indentation being way to large if the method name is really long.

That being said, there are other cases where I want to align things and "a specific size indent" doesn't work

SQL

    SELECT this_column,
           that_column
    FROM tablename
    WHERE this_column = 1
      AND that_column IS NOT NULL

Comments

    /* 
     * Blah blah blah
     * Note: this is interesting because (enough text to want newline)
     *       and also that blah blah
     */

There's lots of places where "alignment" makes sense.

For the SQL case, you can just use a different formatting that puts aligned items into blocks, something like:

    SELECT
      this_column, 
      that_column
    FROM tablename 
    WHERE
      this_column = 1
      AND that_column IS NOT NULL

(The AND token could go either where it is, or at the end of the previous line, depending on your preferences - I prefer the clarity of putting the operator first here over the alignment of the column names, but I can see both sides.)

It might not be your preference, but that's always going to be the case with formatting.

With the comments, that's a good point. I'd generally prefer to use double comments for anything that spans multiple lines, but if you're creating a formatter you need to handle any syntax thrown your way. You could try formatting it without the leading space, but that would be very unusual, or keep the leading space and have it as the one exception to the rule. Or just not format comments, I guess.

For what it's worth, this is how the built in and mandatory Go formatter works and it's "fine".