Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Almost monospaced: the perfect fonts for writing

blakewatson.com

Post reply on HN
Print view View original

61–70 of 174 posts

Re: Almost monospaced: the perfect fonts for writing

#61

Post by andai »

opk wrote: post #32
bsimpson wrote: post #21

Isn't the whole point of monospaced fonts columnar alignment (e.g. the table in the article)? Seems like "almost" defeats the point. Then again, I don't see values lined up much these days: { "someKey": "someValue", "someOtherKey:" "someOtherValue, and if you only care about leading whitespace (that is, the whitespace before a character appears on the line), maybe it doesn't matter how your font is spaced. I suspect…

I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (…

This just seems like a limitation of the technology. When you change the width of one column, the whole table should realign, without any changes to those parts of the file (it's just about how it's displayed).

I recall reading something about "tab stops" that solved this problem, but I don't think there are any mainstream implementations of it.

Re: Almost monospaced: the perfect fonts for writing

#62

Post by adastra22 »

tooltower wrote: post #10

Another reason for using almost monospace: international languages. Many indic languages simply don't have good monospace fonts. It's not easy to design. They stick out in code, as a result. But I've always wondered if allowing three or four different widths would help. We could still align text if (narrow) spaces were the smallest unit, and other widths were repeated multiples of that. This makes me think it's doabl…

Same goes for East Asian languages which are monospaced, but square. If you mix English (or code) with Chinese/Japanese/Korean, you get a mixed-width mess.

Re: Almost monospaced: the perfect fonts for writing

#64

Post by somethingsaid »

kaashif wrote: post #51
bsimpson wrote: post #41

Earlier quoted context omitted.

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.

Here's my reason: if what I see on screen doesn't match the code actually being committed, that freaks me out. Same reason I don't like using those things where <= turns into ≤ in your editor but it's written to disk as <=.

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.

Re: Almost monospaced: the perfect fonts for writing

#66

Post by kqr »

bsimpson wrote: post #21

Isn't the whole point of monospaced fonts columnar alignment (e.g. the table in the article)? Seems like "almost" defeats the point. Then again, I don't see values lined up much these days: { "someKey": "someValue", "someOtherKey:" "someOtherValue, and if you only care about leading whitespace (that is, the whitespace before a character appears on the line), maybe it doesn't matter how your font is spaced. I suspect…

Numbers in many non-monospaced fonts are also monospaced. It's a font feature known as tabular figures.

Re: Almost monospaced: the perfect fonts for writing

#67

Post by bsimpson »

somethingsaid wrote: post #64
kaashif wrote: post #51

Earlier quoted context omitted.

Here's my reason: if what I see on screen doesn't match the code actually being committed, that freaks me out. Same reason I don't like using those things where <= turns into ≤ in your editor but it's written to disk as <=.

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.

Re: Almost monospaced: the perfect fonts for writing

#68

Post by archseer »

andai wrote: post #61
opk wrote: post #32

Earlier quoted context omitted.

I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (…

This just seems like a limitation of the technology. When you change the width of one column, the whole table should realign, without any changes to those parts of the file (it's just about how it's displayed). I recall reading something about "tab stops" that solved this problem, but I don't think there are any mainstream implementations of it.

I think you mean elastic tab stops https://nickgravgaard.com/elastic-tabstops/

Re: Almost monospaced: the perfect fonts for writing

#69

Post by mmis1000 »

andai wrote: post #61
opk wrote: post #32

Earlier quoted context omitted.

I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (…

This just seems like a limitation of the technology. When you change the width of one column, the whole table should realign, without any changes to those parts of the file (it's just about how it's displayed). I recall reading something about "tab stops" that solved this problem, but I don't think there are any mainstream implementations of it.

tab stops is still available in terminals. Tab in terminal move the cursor to next x*8(depends on setting) position independent of what character you input before.

But a major flaw is that it only works when your cell has less than 8 characters. Or it will go to the wrong stop. Which isn't that common today.

Because why insist in short names and 80 width character limit? Almost everyone have a screen that can fit hundreds of characters per line today.

Re: Almost monospaced: the perfect fonts for writing

#70

Post by kevin_thibedeau »

bsimpson wrote: post #41
blakewatson wrote: post #24

Earlier quoted context omitted.

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.…

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.

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.
Post reply on HN