Almost monospaced: the perfect fonts for writing | Hacker News Reader

Almost monospaced: the perfect fonts for writing

blakewatson.com

394 pointsblakewatson171 comments

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 these almost-mono fonts are monospaced, so numerical values should still have nice rhythm too.

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. But why are we making these columns in the first place? Even in a monospaced font they can be finnicky and hard to maintain.

> In virtually every other form of typography, the responsibility of alignment is given to the typesetting application, not the font. If source code editors can highlight syntax, they could also interpret tabs and syntax to create true, adjustable columns of text.

https://input.djr.com/info/

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.

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.

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.

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?

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

IMO, the fact that personalization isn't more widespread is good evidence that code style doesn't actually matter. Humans adapt. So long as it doesn't actually interfere with the function of writing code (eg mixed tabs & spaces; wildly inconsistent identifier names), your reader will get over it quickly after some snide comments to their friends on IRC, and then work on the actual work that needs doing. I think people spend too much thought on this topic.

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 (sorted longest to shortest). For some constant structures a reordering of fields to put the variable length element at the end of the line removes the need for padding space (like in the output of `ls -l` where filenames come last).

A common indentation style for continuation lines is to align with the start of arguments to the function. I've never seen the sense of this variable amount where indentation after a while is much more than after an if. Double the normal indentation for continuation works well in languages where line continuation isn't otherwise distinct from normal blocks.

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/

Elastic tabstops actually mentions the input font in its "see also" section!

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.

> 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

Even without the line length problem, 8 character is unlikely to fit in a meaningful word. And because you need a space between each column, you actually only have 7. And nobody using random abbreviations now.

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

That's often heard, but what's the alternative? So far every other alternative has been more limiting, not?

There are some sane alternatives.

You can keep to mostly text, but give the editor more leeway in how to lay it out and make the code's structure more visible.

Some really simple options, that you might not even recognise as going beyond text: folding of block and go-to-definition.

AST, GUI... The technology is not there yet.

Tab stops are called out in the footnotes:

> Never attempt to line up text by using spaces. The only exception is if you are using a monospaced font. But in word processing applications, there are appropriate tools available for lining up text, like tables[1] and tab stops[2].

[1]: https://practicaltypography.com/tables.html [2]: https://practicaltypography.com/tabs-and-tab-stops.html

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 (to me) than moving my eyes from left to right to spot it somewhere on the right side of the page.

Note how above ALL the punctuation is in the same (first) column, Having read that it then becomes easier to read what is on the rest of the columns.

In general it helps when things that are the same, or have the same purpose, on each line are in the same horizontal position. It is is then easier to see what is different about each line, since it is easy to see what is the same.

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

Thanks, I hate it.

But as long as everything is written under the same guidelines, I will accept it.

Huh, I've always wondered about this style of code formatting and never fully understood why people did it.

Your explanation makes good sense. I guess I just wasn't seeing the forest for the trees. ;)

Languages should allow for leading commas to enable the more uniform:

  [
  , a
  , b
  , c
  ]

Depending on the rest of the language syntax, it could also be nice to have a markdown-style list syntax:

  [
  - a
  - b
  - c
  ]

In JavaScript a leading comma in an array would create a first element whose value is undefined, I believe.

What a stupid design. If the consortium had just one member having the competence of knowing some competing design and using his brain for five minutes, this disaster could have been avoided.

https://news.ycombinator.com/item?id=9624429

Well, JavaScript is pretty much a lost cause anyway.

That's correct, but you can use a trailing comma if you prefer uniform lists:

  [
    a,
    b,
    c,
  ]

I simply prefer :

[ a

, b

, c

]

because, I think this is as 'uniform" as it gets. All syntactic separators are in the first column. Thus they are all uniformly in the same column. Line 1 has the syntactic separator '[' which means start-of-array. Lines 2 and 3 have ',' as the syntactic separator which means element-separator. And line 4 has the final syntactic marker which means "end of Array".

All elements of the array start at the same column, uniformly. And all syntactic separators are in the same column also uniformly.

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

In circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".

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 to do precision work

2) I ended up writing code like

  func(
    arg1,
    arg2,
    arg3
  )

especially with named arguments (arg=value). That aligns even with proportional fonts and all arguments immediately stand out.

If the arguments are few (two or three) and there are no named arguments I don't break them on multiple lines.

The result is that no coworker ever complained about my code.

Languages with a formatter (Elixir) solve the problem once and for all and align well with both kinds of fonts.

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

Honest question: which one is unintuitive?

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.

Viewing the examples generally, the second one better communicates hierarchy at the cost of an extra line. The arguments are all grouped together visually and without distraction, while in the first example the first argument gets muddled with the function name. Why? To save a line break?

The canonical notation is like this:

  func(arg1, arg2, arg3)

the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation.

The argument is already being muddled with the function in the same way.

These conventions are seen in the wild:

  func (arg1, arg2, arg3)

and

  func( arg1, arg2, arg3 )

The real fix for that muddling is to drop the commas, and move the parenthesis to include the function:

  (func arg1 arg2 arg3)

Now func and arg1 are no more or less muddled than are arg1 and arg2. :)

> the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation.

Once you’re splitting it across lines I don’t think that is a desirable attribute. Better to use a format that suits multiple lines than attempt to match as closely as possible to a format intended for one line. Like those “flying cars” that try to look like the “canonical” car.

From my perspective this is a UI problem (though not a serious one).

That’s what many auto formatter do anyways, even ones setup for fixed width fonts.

I do something similar also with if() and others:

  if (condition...
      && condition...
      && condition...
  ) {

Same here but pushed it to force same column condition statement:

    if ((
      condition1
    ) && (
      condition2
    ) && (
      ...
    )) {

But that loses the table-like structure and makes it harder to read.

It should ignore "almost monospace". Most projects have multiple developers, you should assume different developers have different IDE/font preferences, so your formatting shouldn't try to cater for it.

I just put stuff on one line and let the editor wrap them. Doesn't waste vertical space, compatible with any font, any size, any window width, any form factor, the best from all worlds.

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

Many languages also support a comma after the last item, meaning you can still have one line diffs and have a sane reading structure:

    [
      item1,
      item2,
      item3,
      item4,
    ]

This looks bad. Haskell is much better:

  [ item1
  , item2
  , item3
  , item4
  ]

Compare lisp:

    (item1
     item2
     item3
     item4)

Leading comma is better at resolving textual 3-way merges, e.g.:

   [ a         [ a       [ a
   , b         , b    /  , b
   , c   -->   , c   /   , c
   , d         , d  /    , dd
   ]           , e       ]
               ]

Your usual 3 way merge algorithm will correctly deduce:

   [ a
   , b
   , c
   , dd
   , e
   ]

Contrast this with trailing comma:

   [ a,         [ a,       [ a,
     b,           b,    /    b,
     c,   -->     c,   /     c,
     d            d,  /      dd
   ]              e        ]
                ]

You now have a merge conflict between "d," and "dd".

However, if you were to require a trailing comma after the final element you wouldn't have this problem.

> Contrast this with trailing comma:

Example doesn't have a trailing comma. If it did, it would act the same as the leading comma.

But also the leading comma just moves the problem to the beginning of the list instead of the end. Trailing comma with the opening [ on its own line wouldn't have that problem anywhere.

Arguably another problem with lining up code like in the example is that it emphasizes the relationship between the keys and between the values rather than between each key-value pair. This may be useful when writing out matrices but in the example of an object/dict with key-value pairs it seems a distraction more than an affordance.

> ... trying to line stuff up in columns like this in code is a mistake.

I've encountered this sentiment more than a few times and I find it hard to accept. It totally makes sense to align repetitive stuff in columns. That's why people use tables in other contexts, and code should be no different. This alignment makes clear any deviations from the norm and lets you "see" the structure of the data easily.

It doesn't matter for minor stuff and, usually, the code linter/formatter is "good enough"-- but sometimes, you REALLY want to have columnar layout!

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

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.

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.

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.

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.

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.

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.

Another benefit of monospaced fonts is ease of calculation of text-container width: any line x character count will always be the same length as any other.

The main use of this in practice is using line-char-count limits as a proxy to lint for code readability, but it can also be beneficial in other contexts.

If you drop the awkward "3/4" width and just have 0.5, 1, 1.5 char widths, then you could recover alignment by using U+2009 as the half-width space, maybe entered as Shift+space.

From the article:

> You might be thinking, “Okay, but now characters won’t line up neatly.”

I agree "almost" defeats the point, and that columnar alignment is not very valuable, and so there's actually a stronger argument to be made: we should just use normal fonts for coding. What's wrong with, say, Helvetica?

> iA Writer

The typeface is a modification of IBM Plex Mono[0][1]. I'd recognise that 'a' glyph anywhere.

[0]: https://github.com/IBM/plex

[1]: https://www.ibm.com/plex/

Well spotted!

> This is a modification of IBM's Plex font.

https://github.com/iaolo/iA-Fonts/tree/master/iA%20Writer%20...

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

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

Does it? It feels like the "typewriter aesthetic" is pretty much gone. The comically wide thin characters (i, r, l, etc), and comically small wide chars (m, w) are the clearest difference of such a font; without that it looks like a normal proportional font (which it basically is).

See also: Duospaced font https://en.wikipedia.org/wiki/Duospaced_font

That article is strange. I was of the belief that most western "monospace" fonts were in fact "duospaced" under their definition. This distinction isn't apparent for normal writing, but such fonts usually make most emoji two chars wide. This is true at the very least for Adobe's "source code pro", which I typically use. It mentions the OP font as the only western example of such a font, but iA writer doesn't use integer multiples of the base width (necessary to qualify under their definition, as well as under common sense) for M and W.

IIRC it's not that monospaced fonts have double-width emoji; monospaced fonts just tend to not define glyphs for emoji at all, and instead allow the renderer to fall back for rendering of those glyphs to a non-monospaced font in the stack. This may result in emoji taking up basically-arbitrary width in text edit fields, breaking the monospacing.

Terminal emulators, however, have a model on which glyphs are always placed onto a visual grid (the PTY render-model grid, emulating text-mode VRAM); so in a terminal emulator that supports rendering Unicode at all, any glyph will have its visual width "snapped" to an integer multiple of the grid spacing, and will be considered to take up that many grid cells. It is up to the particular terminal emulator where it places the glyph within that array of grid-cells; some left-align glyphs, others center-align.

PragmataPro is an example of such a font. Love it. It comes in a monospaced and duospaced variant. https://fsd.it/shop/fonts/pragmatapro/

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

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

The freeware screenwriting program trelby had some articles that led to one recommending the use of courier prime. I use it when I am working on manuscript copy, it could probably do okay for programming as well.

https://www.1001fonts.com/courier-prime-font.html

Another one you might like is TT2020: https://copypaste.wtf/TT2020/docs/moreinfo2.html This one aims to replicate the ink characteristics of typewriters; there are 9 versions of each glyph that get combined via Unicode rules to simulate the way typewriters would inconsistently distribute ink.

Two big reasons for continuing to use monospaced fonts in programming:

1) Support for vim navigation, where hjkl move you one character in a direction on an evenly spaced grid. Remove that uniform spacing and up ceases to be “up”

2) Legibility for formatted comments and ASCII art (could argue these should be avoided but I’ve seen some magical ASCII art in code)

////////////////

// My Comment //

////////////////

I both use vim movement and a proportional font for coding.

1/ That’s already broken by line wrapping. gj is the command moving up in the grid not j. The fact you are confusing the two should tell you how little of a difference some sideway movement makes.

2/ Don’t use ASCII art in code. It’s annoying for people not using monospaced font and I’m not alone.

Many people map j/k to gj/gk and forget that's not the default behavior.

Interesting, wasn’t aware of gj. I’ve always worked in code bases where a 120 or less character width is imposed, removing the possibility of line wrapping. TIL, mapping j to gj sounds like a good move.

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

Neat idea. This would probably vindicate the “tabs” people of the tabs/spaces debate.

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.

It’s well-defined, at least in the terminal: the east-asian characters are simply double the normal width. There’s a Unicode property to decide which is which: https://www.unicode.org/reports/tr11-2/

I was saying something else. If you mix latin text and Chinese text in a monospaced font, the character boundaries no longer line up.

They still line up (when rendered with correct double-width), the east-asian characters just take up two “slots”, as if they were two normal characters. I don’t know if you see a problem with that, or if you’re talking about renderers and/or applications that don’t correctly handle this double-width logic.

My point is that if handled correctly, e.g. in terminals, there is no problem with that, as long as the application is double-width aware. For example I use Mutt as a mail reader in a terminal, with Vim as an editor, and mixed latin and east-asian characters work fine with them and line up on the terminal grid.

I don't think I've ever seen a double-width font outside of an actual terminal emulator though. It's really frustrating that the fonts used by all IDE's and graphical emacs/gvim/vcode seems have this mixed script spacing issue.

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.

Isn’t that what tab does?

Not really, this is within characters.

This exists as various white space characters https://en.m.wikipedia.org/wiki/Thin_space

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

> Almost monospaced: the perfect fonts for writing

The article doesn’t use the font it is extolling the virtues of, except for illustration. I found that interesting.

Also, there is something that gets under my skin about using anything other than monospaced to write code, as was one of the demo’s. I would genuinely be fine with writing code in a monospaced Arial or Times, but even courier-semispaced makes me shiver inexplicably.

> The article doesn’t use the font it is extolling the virtues of, except for illustration. I found that interesting.

I do use them for writing and coding.

Don’t misread what I am saying: I am not judging you for finding something that works for you, or attacking you for sharing.

I’m bummed out to see an article about “a perfect font”, especially being a monospaced one (or nearly), but that does not use said font throughout. I was sort of hoping to be immersed in this font for awhile, but wasn’t.

I use fira+ligatures. I am a monospacer too.

I think the point of the article is that monospaced fonts, or near-monospaced, are good for production (writing), though arguably proportional fonts are better for consumption (reading).

Yeah this is my anecdotal take. Haven’t looked at studies on this, if they exist, but in my experience, reading monospaced fonts for several paragraphs is tiring.

I must be misunderstanding your meaning, what forms of writing don’t also require reading in the form of rereading?

As far as I know, "American Typewriter" is basically the original "almost monospace" font:

https://en.wikipedia.org/wiki/American_Typewriter

Here's proportional font for camelCase programming. It adds a padding to the left of the capital letters, and has a much wider space character.

https://ericfortis.com/portfolio/design#-verdana-camel

---

For aligning content, I think IDEs should be able to represent some parts of the code as tables. For example, similar to the Decision Tables of Jetbrains Projectional Editor:

https://youtu.be/iN2PflvXUqQ?t=357

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.

Verdana is the font of the New Millennium and I will not entertain competing suggestions

> Verdana (as used on this very HN)

Hm. If Verdana is the render font for you here on HN, I believe that's that's all about your browser config, and nothing about HN.

HN does specify Verdana, so that's what you'll see unless the browser is overriding that somehow. See https://news.ycombinator.com/news.css

Oops, you are quite right!

I do override it, for more than ten years. That's what I get for posting without sanity checking myself.

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.

I fully agree, but sadly its character set is rather limited in terms of Unicode characters.

Input is a great programming font. It also lets you customize a bunch of options (e.g. slashed-0, loopy-a or g, serifs on i/l, etc). Free download for private use[0].

[0] https://input.djr.com/download/

I love writing with monospaced fonts (just as the author of article says, they look "writerly"), but I detest the fonts in iA Writer. I just can't stand to look at them, so I don't use the software (which would be great if it allowed me to choose other fonts). I also hate Courier New, which is a weak and spindly font. My favorite is Courier Prime.

Take a look at Drafting* Mono: https://indestructibletype.com/Drafting/

This is a great font! It feels to me almost like a 'handwritten' version of the font I use, [Julia Mono](https://juliamono.netlify.app/)

Wow, this is amazing! Thank you for sharing.

Oh, that guy and his stupid habit of putting an asterisk in the font name—impossible to use in Emacs.

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

Yeah, if everyone was used to reading monospaced fonts then proportional fonts would be hard to read. I suspect there might be a bit of an advantage for proportional in terms of ultimate reading speed in that you might be able to fit in an extra word in your scan, but the alignment of a fixed grid might help a bit too. The real value of proportional fonts is that you can print more stuff on the page and make your book shorter and cheaper. In today's world the paper is basically free, so that is no longer an issue. It just means that you have less text on the screen and will have to page a bit more often.

I have to disagree a bit. Even stipulating that there may be some economic drivers for more compact text, my observation is people largely switched to using proportional fonts (outside of some specialty cases like code or tabular data) as soon as it was technologically possible to do so. People generally preferred proportional fonts when it was practical to use them with the equipment reasonable at their disposal.

I’d say that for coding the critical bit is not “things lining up” — it’s a bad practice anyway — but wide and clear punctuation (`[{(` &c).

I use iA Writer Duo for writing prose and fiction a lot.

If you're willing to pay for typefaces, though, there's a really good "almost typewriter" font called Triplicate, which comes in four versions -- the original, a slight variation with the same metrics as Courier, a "code" version that has a few characters changed to be better for coding (this is a great alternative to the more expensive Operator Mono, in my experience), and a proportional one which fits the "almost monospaced" idea. (It's not designed for coding, but I don't think proportional fonts work for coding in most editors.)

I love Matthew Butterick's fonts (eg, Triplicate). The license for his fonts is perhaps the most generous I've seen when it comes to commercial fonts.

A link for those interested: https://practicaltypography.com/triplicate.html

Unfortunately applying both Poly and Code gives you an imperfect result: the default l glyph has a flat base, Poly makes it narrower, and Code makes it a curly tail, but enable both (e.g. font-feature-settings: "ss01", "ss02") and you get the Poly glyph rather than the Code glyph or a hybrid, both of which would be nicer, and MB has said “won’t fix” (and I haven’t gone to the trouble of patching it myself).

A demo of my own of Triplicate with use of both Poly and Code: https://chrismorgan.info/blog/rust-fizzbuzz/, code is all Poly + Code, compiler errors are just Code (it uses columnar alignment, so not Poly). The lowercase l can be seen in all the figures in one form or another (e.g. “else” in bold, “result” in regular, but not “println!” because italics always uses a curly-tailed l).

I'd never actually tried to enable both at once, but I'm not surprised it doesn't work. I love writing prose with Triplicate Poly, but I code with monospaced fonts, as neither most code editors nor most codebases seem to work that well with proportional fonts.

I just flat-out prefer the Code variant’s glyphs to the default ones in every case. Especially the l, which is what makes the Poly + Code handling unfortunate.

I like your taste – Input and IBM Plex (on which the iA Writer family is based) are my favorites as well. iA's old typeface Nitti is great as well.

Nitti is the OG monospaced writing font for me. Soon as I experienced it on those older versions of iA Writer I was hooked. I do love IBM Plex and these derivatives but I also miss Nitti. Might have to pick that one up from Bold Monday for old times' sake.

There's an easy solution to stop worrying among input, iosevka, source code pro, consolas, and the like: https://en.wikipedia.org/wiki/Andalé_Mono

    $ brew tap homebrew/cask-fonts     # You only need to do this once!
    $ brew install font-andale-mono

Of course, most other recommendations in this thread are available as well:

https://github.com/Homebrew/homebrew-cask-fonts/tree/master/...

These land in the same folder as user installs through Font Book. Using homebrew makes moving to a new system as easy as bundling the Brewfile.

I’ve thought about ideal fonts for both writing/reading and programming quite a bit, and have been let down at the choices out there. It seems most popular monospace fonts (Fira Code, Iosevka, Ubuntu Mono, etc) attempt to either fit as many characters on the screen as possible, or are so wide, that larger sizes make it impossible to fit even a function on screen; both design choices hurt overall readability and end up forcing me to fiddle with line spacing, sizing, and custom font versions just to be somewhat happy. At this point I’ve just stuck to putting consolas on virtually every machine I use, but that’s also not great.

I really hope some font foundry out there focuses on designing something specifically for readability of large bodies of monospace/duospace text.

It’d also be nice to have a provable metric for readability, rather than the anecdotal evidence I tend to see, but I suspect this is hard in and of itself.

I am not convinced. They should just finish the fitting/kerning. Seems like a fad more than anything else.

In the screenshot, if you were to see a properly fitted proportional version of iA Quattro, you'd ditch iA Quattro. But that comparison is not presented, I don't think they've tried making a proportional version of it.

That’s a good point. Something close to a "properly fitted proportional version of iA Quattro" might be Nitti Grotesk. https://www.boldmonday.com/typeface/nitti-grotesk/

It's like this: A) Here is an unbaked cake. B) Here is a half-baked cake. But, the argument they are making is B) is better than C) Fully baked cake. No fully baked cake is presented for evaluation.

You can't use Nitti Grotesk, a cookie batter, to make an argument here either for a fair comparison. It's an entirely different thing.

In order to do a proper comparison, they should finish the kerning job and present their arguments fairly and squarly.

The image I am talking about is: https://i0.wp.com/blakewatson.com/wp/wp-content/uploads/2022...

It needs a 3rd line "iA Writer Proportional". Looking at the word "next" in iA Quattro, the fitting looks really bad which is a known trade-off in monospaced typefaces, but not an excuse to leave it like that in a proportional typeface.

Similarly, the image with Input Mono caught my eye: https://i0.wp.com/blakewatson.com/wp/wp-content/uploads/2022...

The word "chain" looks more like "cha in" which just makes the font seem unfinished to me.

This stuff is like nails on a chalkboard to me. It is extremely unpleasant :-) It makes me appreciate good typefaces more, my favorites being anything designed by Matthew Carter. Legendary: https://en.wikipedia.org/wiki/Matthew_Carter

My use case for monospace is actually to align things perfectly when I write code.

/Almost monospace/ is probably great _for writing_, but I find it a bit frustrating that the author doesn't address lining up things with /almost monospace/...

It'd be interesting to have an eventually-consistent monospaced font that adjusts the widths of characters like `w` and `i` such that when they're within a few characters of eachother they become more proportional. Obviously adjacent characters can be done with ligatures so `wi` is still 2 char-widths wide, but aren't modern font-rendering systems smart enough to do more than ligatures with alternatives? I wonder what it'd feel like to watch these characters adjust width as you type.

This is the first time I've heard of iA Writer, it looks like exactly what I need right now for nanowrimo... focused on writing prose with some minimal feedback tools. Going to give it a shot!

My first time seeing it too, it really does look appealing! I am using Scrivener's very generous Nano demo this year (https://www.literatureandlatte.com/nanowrimo). Free from Oct 15 - Dec 7, and at the end of that you get a 50% discount if you hit 50k words, which is pretty cool. So anyway, I've got my outline and stuff all in Scrivener but maybe I'll try iA next year, or for some other markdown writing work. It kind of reminds me of what Tomboy notes felt like in GNOME back in the day.

Two years ago, I did nanowrimo in Vim with a whole suite of plugins:

- https://github.com/preservim/vim-pencil

- https://github.com/junegunn/goyo.vim.git

- https://github.com/junegunn/limelight.vim.git

- https://github.com/vimwiki/vimwiki

It was fun, and the setup is almost identical to iA Writer which I appreciate. I even had it all on my phone with Termux!

Last year I just did it in Markdown in VSCode in "zen mode" which also worked pretty well. It was definitely easier to setup than Vim and had better highlighting of bold/italics/etc.

Good luck! I'm also doing Nano and was supposed to be working on my novel but instead I wrote about the font I was using.

I prefer Source Code Pro for the terminal:

https://adobe-fonts.github.io/source-code-pro/

Source Code Pro was my go to for a long time ( https://blog.typekit.com/2012/09/24/source-code-pro/ gets into the design of it) - the 1Il|iO0oB8 set is where its most interesting to me (and why I liked it).

However, when Jetbrains Mono came out, I switched my code editors to it (IntelliJ was trivial) - https://www.jetbrains.com/lp/mono/ (and no, I don't like ligatures). The slightly larger lowercase high at the same font size makes it a bit easier to read without boosting the entire editor's font size up, the 'g' debate I lean to the single story, open tail form ( https://www.typeroom.eu/the-elusive-mystery-of-letter-g-expl... ).

I enjoy in Source Code Pro that every character is unambiguous...

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

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.

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

Reading is a big part of writing, and I'm not sure how almost monospaced fonts would perform for reading. Probably about average, if the conclusions from this study are correct: https://www.nngroup.com/articles/best-font-for-online-readin....

Iosevka, a customizable monospace font, also has quasi-proportional (almost monospace) varients: Iosevka Aile and Iosevka Etoile.

I use a lowercase “L” and “LST” (in lowercase) for variables representing lists in function args.

For me the lower L and the number 1 have to be different. Most mono fonts make them almost identical.

Typing “lst” looks like 1st (First). They either need to curve the bottom of the lowercase “L” or remove the bottom bar of the one.

In the iA Writer Quattro font sample look at the kerning in the word "buckles". You could drive a bus through the gap between the 'u' and the 'c'.

https://www.jetbrains.com/lp/mono/

I think when a font has all the characteristics of being monospaced like large serifs etc., but actually isn't, it looks subtly "off". I remember distinctly the user manual of a motherboard I had near the turn of the century somehow had screenshots of the BIOS setup utility rendered in almost-monospaced Courier New, and it looked sufficiently weird that it was distracting.

Courier New is monospaced.

https://support.microsoft.com/en-us/topic/microsoft-supplied....

I know it is; but they had somehow managed to change the glyphs spacing so that it isn't, yielding the same odd effect that I see in the sample in this article.

Not sure if it's the font, the colors, the kerning, or my browser, but this website hurts my eyes!

Sorry to hear that. There's a toggle switch for light mode if that helps.

Proportional “typewriter” fonts are an old idea. TeX has them (cvtt).

To each their own, but this reads to me like an April Fool’s post.

Is it possible to use a font like this in a terminal emulator?

See also: a little bit pregnant, almost alive, and close but no cigar.

Yes, I read the article to the end. No, I don’t get it. Either they line up or they don’t. Either it’s monospace or it’s not.

Within the fonts that aren't monospace, some fonts have less variation in glyph width than others. It's a spectrum. You can choose a font that is mostly monospace, but not completely, to confer benefits for readability.

If all you're saying is that you personally don't care to make a finer distinction than monospace/proportional, that's fine, but it's probably not worth commenting on either.

There is nothing that says monospaced fonts are more readable. In fact, they’re probably not since you can’t give neither whitespace nor character components like the ascenders/descenders/bowls/stem/etc the space they need to shine relative to each other.

Monospace has one and only one redeeming quality that makes it worth using over proportional fonts: it lines up.

This is great. I am going to try it out.

Meta: Why is HN obsessed with typography?

HN likes beautiful code.

HN likes beauty.

Programmers work with text all day. We think of that text we work with as the subject matter very often and that sparks lively debates.

There could also be an element of tradition; prestigious institutions and individuals, like Bell Labs, Donald Knuth and Apple, have devoted significant resources to typesetting and publishing, so an appreciation for typography could be seen as a marker of sophistication from that.

And lastly we must often have some working knowledge of the design of user interfaces at some point in our careers, and you need to have some notions of typography to be effective at that.

Something that converts abstract glyphs to bezier curves and projects that to your eyes deserves attention and care. Typefaces bring the abstract idea of what a glyph is semiologically, to the physical 2D space. Made up of bezier curves, the have to abide by conventions but have considerable room in expressivity as well as design intent for a specific purpose. Typefaces are fascinating and the process of designing them is underrated and unappreciated by public at large. Billions of people rely on them, they're everywhere and you interact with typefaces all day, everyday.

Because many HN readers are developers, and developers deal with characters all the time

Reply on news.ycombinator.com