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

111–120 of 174 posts

Re: Almost monospaced: the perfect fonts for writing

#111

Post by WithinReason »

Cthulhu_ wrote: post #108
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…

You know, now you mention it, I thought about this and realized I mainly want items to START on the same column, after that I don't care; only exception is tables in markdown, but those are few and far between. I might give these fonts a try, although I've been used to Menlo for a long time.

I wonder if it would be possible to create a font that is not monospaced for letters but it's monospaced for words, so if you have a word + white space the end of the white space is the same as it would be with a monospace font. Alternatively, one could write "alignment characters" like & if one wanted to align lines like in LaTeX formulas.

Re: Almost monospaced: the perfect fonts for writing

#112

Post by thaumasiotes »

mikojan wrote: post #105
thaumasiotes wrote: post #88

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

This looks bad. Haskell is much better: [ item1 , item2 , item3 , item4 ]

Compare lisp:

    (item1
     item2
     item3
     item4)
;p

Re: Almost monospaced: the perfect fonts for writing

#113

Post by hoseja »

galaxyLogic wrote: post #106
rocqua wrote: post #84

Earlier quoted context omitted.

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.

> the value is communicating the structure of the code. I agree and I think that is the same thing as code-readability. Code-readability means you can easily understand the code. I personally try to abide by what I call "hedge" formatting convention, the punctuation forms a vertical hedge which then shows the structure of your code clearly: [ a , b , c ] Moving my eyes down to look for the closing bracket is easier (…

Yes, this is what I've also gravitated towards.

Re: Almost monospaced: the perfect fonts for writing

#114

Post by rob74 »

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…

Yeah, that's why I'm skeptical about these "almost monospaced" fonts too. In my opinion, the actual problem is sans serif monospaced fonts: there most of the glyphs are sans serif, but then the designers are forced to add serifs only to the narrow glyphs to fill up the available space, so these end up sticking out like sore thumbs. So monospaced fonts that have serifs on all glyphs look much better IMHO.

Re: Almost monospaced: the perfect fonts for writing

#115

Post by oneeyedpigeon »

kstenerud wrote: post #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 d…

"The difference is subtle"

I noticed the difference immediately — but not in a good way. I just felt a much stronger preference for the version on the left, the true monospace. I initially put it down to the indent — that "n" beginning "num" just looks horribly placed wrt to line above it — but, on reflection, I think it's the 'sans' properties that make it less pleasant for me — like the "i" and "l" in "while" that are much rounder and, of course, without even slab serifs.

Re: Almost monospaced: the perfect fonts for writing

#117

Post by rrwo »

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…

Typewriters and dot matrix printers were monospace. It had nothing to do with lining code up.

When I attended university in the mid-1990s, and again in mid-2000s, we were required to hand in papers using monospace font, black ink, with a specific point size and margins.

It kept everything looking consistent with typewriters (which some people still used through the 1990s), but also kept people from using distracting or illegible fonts, or trying to work around page or word limits by using different fonts.

Re: Almost monospaced: the perfect fonts for writing

#118

Post by alpaca128 »

anilakar wrote: post #102
pmontra wrote: post #97

Earlier quoted context omitted.

I've been using proportional fonts in programming for about ten years. I stopped doing things like abc = 1 d = 2 which add very little readability value IMHO. Things like func(arg1, arg2, arg3) usually don't align well because func( has a different width than the five spaces in the lines below. However 1) my text editor (emacs) aligns those lines for me (probably any programmer's editor does) so at least I don't have…

Formatting your code in an unintuitive way because of the font is a code smell to me.

Why? The purpose of code is to be readable to humans.

At the same time I get your point and also the argument about Git diffs (which also should be readable). So maybe the ideal situation would be a separation of code and its formatting, so that we have more options than tabs and also no need for crutches like tabs. Like a better, more flexible code formatter that lets you display and edit code in the editor using one style but then saves the file in a standard format that's consistent across the whole project.

Re: Almost monospaced: the perfect fonts for writing

#120

Post by eru »

mmis1000 wrote: post #69
andai wrote: post #61

Earlier quoted context omitted.

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

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

Yet, books don't work that way, even though we have the technology. Long lines aren't readable. There's a reason newspapers have columns.

See eg https://baymard.com/blog/line-length-readability and https://en.wikipedia.org/wiki/Line_length

Post reply on HN