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

81–90 of 174 posts

Re: Almost monospaced: the perfect fonts for writing

#81

Post by fbdab103 »

flobosg wrote: post #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,…

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

Buried the lede on that one. Was looking forward to the recommended typewriter font.

Re: Almost monospaced: the perfect fonts for writing

#82

Post by jen20 »

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…

This “feature” of lined up values annoys the hell of me when using Go (in particular) and also seems prevalent in Ruby-derived things. IMO unless you pinstripe line backgrounds, it makes it harder to trace which value maps to which key in the presence of a single longer key name. It also leads to noisier diffs.

Re: Almost monospaced: the perfect fonts for writing

#84

Post by rocqua »

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

The value of alignment (at least for me) is not in making the text of the code more readable. Instead, the value is communicating the structure of the code.

Seeing the same shape repeatedly tells me a lot about what is happening. It also helps highlight changes between two lines that are very similar.

Re: Almost monospaced: the perfect fonts for writing

#85

Post by ako »

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

I stopped manually formatting code long ago, just accept what the code formatter tool decides is good enough. Saves a lot of time.

Re: Almost monospaced: the perfect fonts for writing

#86

Post by tapanjk »

> But there is a reason we don’t use monospaced fonts everywhere. They are somewhat hard to read because [...]

Well, not sure what is the basis for that assertion, but I find it easier to read text rendered in a monospaced font (Courier is my favorite). In fact, when I need to read something longer than a minute on the browser, I switch to monospace (with help of a browser plugin). It's not about text alignment -- it does not matter when reading prose, but perhaps about the familiarity of a font.

As an aside, I also try to get rid of formatting when reading long text. It allows me to focus on the essence of the written word. Perhaps, this is why the old school mailing lists and message forums are more appealing than the modern crop of social media apps. Also plain text email (what a rarity in the corporate world today!).

Re: Almost monospaced: the perfect fonts for writing

#88

Post by thaumasiotes »

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

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

Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this:

    [item1
     ,item2
     ,item3
     ,item4
    ]
instead of a sane way. It means adding or removing an element only changes one line in the diff!

Who cares? It's not hard to understand what's happening in a diff that makes this kind of change. You want the code to be easy to read, not easy to diff.

You could also easily base your diff algorithm on a lexer for the language rather than a lexer for ascii, in which case changing the amount of whitespace would register as "not a change".

Re: Almost monospaced: the perfect fonts for writing

#89

Post by karmakaze »

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…

If spaces had half-width, then the Duo could still use spaces for alignment, though monospaced text would need to be run through a filter.

Re: Almost monospaced: the perfect fonts for writing

#90

Post by kristiandupont »

c-smile wrote: post #14

For some reasons, I've found that good, old, Verdana (as used on this very HN) is the most editor/writer friendly. IMHO of course.

I used to use it as well.

I stopped because the spaces are too small for my liking. It worked when I was using 4 spaces for indentation but now the more or less agreed-upon standard is 2 (for JS/TS which I mostly write). I wish I could create a custom version with a larger space.

Post reply on HN