Live data from Hacker News

Almost monospaced: the perfect fonts for writing

blakewatson.com

71–80 of 174 posts

Re: Almost monospaced: the perfect fonts for writing

#71
"You might be thinking, “Okay, but now characters won’t line up neatly.” Thats true, but the upside of this sizing means you still retain the typewriter aesthetic with a bit more legibility. Notice the difference?"

Umm... no?

"The difference is subtle but notice that the sample on the right gives letters like lowercase “m” a little leg room, improving the readability of the code."

Uhh... If you say so...

I honestly don't see any of the upsides he's talking about. But the downside of things not lining up is definitely real.

Re: Almost monospaced: the perfect fonts for writing

#72

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.

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?

Re: Almost monospaced: the perfect fonts for writing

#73

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…

With non-monospaced fonts, it doesn't matter how many or how few leading spaces you insert, the columns may never line up, and your IDE can't determine them automatically.

With monospaced fonts, the columns will be guaranteed to line up with the correct number of spaces, which your IDE will determine anyway.

Re: Almost monospaced: the perfect fonts for writing

#74
Meanwhile, at the other extreme, in many proportional fonts the widths of letters vary so characteristically that clever readers can decode a text mostly just from the widths: see Donald Knuth's "N-ciphered texts": https://digitalcommons.butler.edu/cgi/viewcontent.cgi?articl...

(Not linking the solutions here to make it harder to spoil the puzzle, but you can find them online with a bit of effort — maybe this will help: https://digitalcommons.butler.edu/cgi/viewcontent.cgi?articl... — and it's also reprinted in Selected Papers on Fun and Games.)

Re: Almost monospaced: the perfect fonts for writing

#75

"You might be thinking, “Okay, but now characters won’t line up neatly.” Thats true, but the upside of this sizing means you still retain the typewriter aesthetic with a bit more legibility. Notice the difference?" Umm... no? "The difference is subtle but notice that the sample on the right gives letters like lowercase “m” a little leg room, improving the readability of the code." Uhh... If you say so... I honestly d…

Too true. The only reason to use monospace is to line up the characters.

If I don't need characters lined up I can use just about any font there is.

So this font is not competing with monospace fonts, it's competing with all non-monospaced fonts, so there's really no advantage in using it.

Re: Almost monospaced: the perfect fonts for writing

#76

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.

Ask and receive: https://blog.jetbrains.com/idea/2022/11/intellij-idea-2022-3...

Re: Almost monospaced: the perfect fonts for writing

#78
A while ago, while repurposing an old laptop into a distraction-free “typewriter” I researched fonts with a typewriter-like aesthetic. Here’s what I found:

Sun Gallant Demi, Solarize, Libertine/Libertinus Mono, Triplicate, Prestige Elite, CMU Typewriter, Latin Modern Mono, MingLiU, sony-misc, Verily Serif Mono, Century Schoolbook Mono BT, UM Typewriter, American Typewriter, Courier, Pitch, TiredOfCourier, Xanh Mono, DSE Typewriter, LTC Remington Typewriter, Bitstream Pica 10 Pitch, Italian Typewriter, Typist Slab, FF Elementa, EF Techno Script, Drafting* Mono, Bodoni Egyptian Mono.

(I don’t remember which one I ended up using, though.)

Re: Almost monospaced: the perfect fonts for writing

#79

It would be nice to have a space character for the 50% or 150% width some of these letters use. That way you could still line things up if you chose to do so.

Would be neat to have ligatures, for example for lowercase i followed by space, to restore column alignment.

Re: Almost monospaced: the perfect fonts for writing

#80
post #61
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.

Writing programs by manipulating text is the actual limitation of the technology here, alignment is just a minor detail by comparison.
Post reply on HN