But if the syntax was separate from the underlying representation, couldn't you just have your editor open it the way you want?

But if you just always indent by n tabs, and align with spaces for visual alignment, then it's not a problem. This is what e.g. gofmt does.

(This isn't the best example of what I'm getting at, but it's easy to grasp. A stronger example would be the use of ternary operators with multiple lines of JSX. There are many "micro-syntaxes" or "micro-layouts" that help readability and form common patterns in code bases which don't play well with tabs-for-indents, so when you use tabs, you have to train your team to develop and accept novel versions of these "micro-layouts".)

In other words, instead of:

    def my_func(self,
                param):

    def my_func(
        self,
        param,
    ):

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.

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.

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

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

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

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.

Code is so incredibly hard to mentally grasp and every mental overload should be omitted to reflect on the logic.

There is a reason why there is one code basis and this should always be curated by a linter to uniformly enforce a standard.

There is still plenty of room for style and code organization.

I witnessed first hand many trench wars around seemingly small things like curly brackets in IF statements dealing with the question of one white space or none, because it appealed to personal preferences and before ESlint people would go to great length reformatting hundreds of LoCs just to get their right feeling of code syntax.

Weird. And git -diff was massive, as well as the code reviews.

(Un)Happy times. :D

You can configure ESLint to use prettier, but in my experience it's usually easier to just run ESLint separately to prettier.

>Maybe we'd have editors and viewers where you could configure the syntax however you wanted

I took this to mean that, in this fantasy universe, you could make any source file look however you want. Like tabs vs spaces and pure html vs html-with-css, this is about separating meaning from presentation. Is there a good reason to force the same visual representation on everyone?

Leaky abstractions. If there are two different visual representations then sometimes someone using one representation will need to think about the other.

* Would such bytecode/binary be considered "source code"? If no, then bye bye Open Source Definition (OSD). Distributing such thing would not be considered open source.

* If it is considered "source code", then is it considered "obfuscated" source code? If yes, then bye bye OSD. Distributing such thing would not be considered open source.

* If it is not considered "obfuscated" source code, then what's the difference compared to, say, JVM bytecode? Is it only that an IDE exists that can modify such bytecode in a fancy way?

* In that case, if such an IDE is created that modifies JVM bytecode directly, and a program is created using that IDE modifying the JVM bytecode[1] directly, and such "source code" is distributed, the would that bytecode be open source? Since, after all, it's "the preferred form in which a programmer would modify the program" (and therefore not obfuscated).

[1]: Or maybe some superset that is mostly JVM bytecode but it has some opcodes for higher level niceties.

I’m all for keeping consistent flat utf-8 files. I’d hate for my code ultra simpleminded, possible to pen test with a pen and paper, python and sql code to be wrapped in a god awful xml or json or proprietary db markup and object hierarchical model of what code should look like.

Like I imagine trying to check in a jupyter notebook but worse.

For instance tabs vs spaces was decided and text editors accommodated this and despite what may be someone’s personal preference a uniform decision was made.

Humans can learn. We should use accessible formats and push for standards and keep those readable.