This seems to be an unpopular opinion, but proportional fonts are great.
One question people sometimes ask is, "How can you code in a proportional font? How do you line things up in columns?"
The answer is you don't. For example, the Black code formatter for Python completely eschews column alignment of this sort:
foo.bar(one,
two,
three)
(Imagine that the words were long enough that the whole thing wouldn't fit on one line.)
Instead, Black formats it like this:
foo.bar(
one,
two,
three
)
No column alignment, only indentation. Code formatted like this is equally readable in a proportional or monospaced font. You don't need monospaced fonts!
I've read and written all my code in proportional fonts for close to 20 years. My current one is Trebuchet++, a variant of Trebuchet MS that I customized in FontForge.
Trebuchet MS is pretty good on its own. For example, all of the "confusable" glyphs are easy to distinguish. And it renders very nicely on a high-DPI display.
Its tilde is pretty bad, though. It's tiny and almost looks like a hyphen. So that was the first thing I fixed, putting in a better tilde.
Then I experimented with spacing for the _ and . glyphs. I added negative margin on both sides of the _, while keeping its width. And I added positive spacing on both sides of the . glyph. Consider code like this:
snake_case_name.another_snaky_name()
These spacing changes have the affect of pulling the individual words in each name closer together, while increasing the separation between the two names.
It is subtle, but to my eye it helps readability.
Next up will be to add some positive margin inside the three pairs of brackety things: (), [], {}. I have always found that it helps readability to add a space inside parens and such, but most contemporary code formatters prohibit this. With a proportional font I can tweak the font to put some visual spacing there.
I don't like the extra lines, but also I almost never care if "one" is exactly lined up with "two". You can use proportional fonts with the first example too.
You dismissed the idea as "if you stop doing thing which benefit from monospaced fonts", suggesting that monospaced fonts are better in this situation.
My argument is that both fonts are just as good in this situation, and monospaced fonts aren't benefiting here. You don't need monospaced fonts to use formatting 1, you can just choose formatting 1 and then use either kind of font.
Having the "one" line up with the "two" is the benefit here, and the point of the monospaced font. If you don't care about that, fine. But objectively lots of people do.
Well I'm saying that it does still line up in a reasonable sense, at least from the perspective of someone that would use a proportional font at all and isn't looking for a grid.
It's important to note that I'm not comparing monospace versus proportional. I'm saying that "formatting 1 with proportional font" isn't really worse than "formatting 2 with proportional font". Both of them are going to have problems from someone that really likes monospacing.
For me it's not about lining things up in columns as much as it is about column widths. So, for example, hitting up or down, I know which character the cursor is going to go to (which means I can string keypresses together and do them in a fluid movement). Putting in a hard limit for line lengths (which is very important to me, I know opinions on this differ) means that limit can be drawn as a literal line on the UI (which in turn means I know how small I can resize the editor pane to be). Similar lines with slightly different values (e.g. 'x', 'y' and 'z') will line up so the different values are underneath each other everywhere they appear in the line (also those lines will be the same length which reassures me those lines are the same outside the variables/values).
One question people sometimes ask is, "How can you code in a proportional font? How do you line things up in columns?"
The answer is you don't. For example, the Black code formatter for Python completely eschews column alignment of this sort:
(Imagine that the words were long enough that the whole thing wouldn't fit on one line.)Instead, Black formats it like this:
No column alignment, only indentation. Code formatted like this is equally readable in a proportional or monospaced font. You don't need monospaced fonts!I've read and written all my code in proportional fonts for close to 20 years. My current one is Trebuchet++, a variant of Trebuchet MS that I customized in FontForge.
Trebuchet MS is pretty good on its own. For example, all of the "confusable" glyphs are easy to distinguish. And it renders very nicely on a high-DPI display.
Its tilde is pretty bad, though. It's tiny and almost looks like a hyphen. So that was the first thing I fixed, putting in a better tilde.
Then I experimented with spacing for the _ and . glyphs. I added negative margin on both sides of the _, while keeping its width. And I added positive spacing on both sides of the . glyph. Consider code like this:
snake_case_name.another_snaky_name()
These spacing changes have the affect of pulling the individual words in each name closer together, while increasing the separation between the two names.
It is subtle, but to my eye it helps readability.
Next up will be to add some positive margin inside the three pairs of brackety things: (), [], {}. I have always found that it helps readability to add a space inside parens and such, but most contemporary code formatters prohibit this. With a proportional font I can tweak the font to put some visual spacing there.