Yeah, you’re right. You lose columnar alignment but beginning indentation still aligns and, in Input Sans, I believe the numbers are tabular. David Jonathan Ross makes this argument in the explainer for Input:
> Sometimes programmers rely on the monospaced grid to create a second column of values or comments on the right side of the page. It’s true, these secondary columns won’t align in a proportionally spaced font. But why are we making these columns in the first place? Even in a monospaced font they can be finnicky and hard to maintain.
> In virtually every other form of typography, the responsibility of alignment is given to the typesetting application, not the font. If source code editors can highlight syntax, they could also interpret tabs and syntax to create true, adjustable columns of text.
I still can't believe personalization isn't more widespread in coding. For instance, it ought to be reasonably trivial to set up your formatting preferences in your editor, but have the file saved to disk be in a common format.
You want 8-space tabs and braces on their own lines? Cool. We'll save the file with all the formatting defaults, but run a formatter tuned to your preferences before displaying.
Similarly, for some languages the meaning of what is written can change based on the indentation and line breaks. Or a statement written under one formatting standard can become significantly harder to read under a different formatting standard.
There are plenty of automated formatters - clang-format, prettier, gofmt, black. You would delegate to one of them, configurable in the project/editor, and adjustable by file extension.
If the code doesn't parse, save it as-is. If it does, run the formatter with the defaults before saving. When opening, run the formatter with the user's preferences before displaying.
Gets you the benefits of a formatter, with the freedom to control your environment to your tastes. You can already pick your editor, font, and color theme. You ought to be able to pick your formatter settings too.
Accurate reporting of the error positions is one reason this is a non-trivial thing to implement. It's a fixable problem, just takes quite a bit of tooling and complexity for a good experience, and all things considered: is it really worth it?
This invariably leads to fucked up diffs and useless blaming. In theory tabs are superior as a way to provide configurable layout but as soon as you have to collaborate between users with different tooling you end up in a mixed whitespace hellscape.
IMO, the fact that personalization isn't more widespread is good evidence that code style doesn't actually matter. Humans adapt. So long as it doesn't actually interfere with the function of writing code (eg mixed tabs & spaces; wildly inconsistent identifier names), your reader will get over it quickly after some snide comments to their friends on IRC, and then work on the actual work that needs doing. I think people spend too much thought on this topic.
> Sometimes programmers rely on the monospaced grid to create a second column of values or comments on the right side of the page. It’s true, these secondary columns won’t align in a proportionally spaced font. But why are we making these columns in the first place? Even in a monospaced font they can be finnicky and hard to maintain.
> In virtually every other form of typography, the responsibility of alignment is given to the typesetting application, not the font. If source code editors can highlight syntax, they could also interpret tabs and syntax to create true, adjustable columns of text.
https://input.djr.com/info/