While I'm here: Victor Mono has been my programming font of choice for a while now: https://rubjo.github.io/victor-mono/

Oh, look at that, the Victor Mono homepage has a font comparison slider that allows you to compare it to MonoLisa! MonoLisa advertises that it's wider than other monospace fonts, and you can really see that in the comparison. One of the things I appreciate about Victor Mono is that it is narrower than many other monospace fonts (while still being very readable), allowing you to fit more code side-by-side.

https://www.programmingfonts.org/#font3270

BTW, I'm also a huge fan of Luxi Mono, but I edit it and add a dot in the middle of the zero to make it different from the O. I like it because it reminds me a bit of the Sun console font (which I always forget the name). I could also go with Go Mono, which is mostly the same, but has a slashed zero.

edit: if you hate my font, just don't use it. You don't have to downvote this. ;-)

I think it is wild that so many of us have these very strong, yet radically different, opinions.

[1] https://www.cambus.net/spleen-monospaced-bitmap-fonts/

Side note: it's a bummer that you never see Monaco on these comparison tools. Monaco has been my monospace font of choice for many years now despite never owning a Macbook: https://github.com/cseelus/monego

In case you like narrow but Victor’s not your thing, I can enthusiastically point you towards Iosevka. (That’s also available in Victor’s comparison picker. Nice!)

  $ brew tap-info "homebrew/cask-fonts" --json | jq -r '.[].cask_tokens[]' | rg victor
  homebrew/cask-fonts/font-victor-mono-nerd-font
  homebrew/cask-fonts/font-victor-mono

https://github.com/braver/programmingfonts

edit: ahhh it's a paid font.

so nope

Serifs are known to be less readable on screens. Each to their own but to me that MonoLisa thing is sort of half-serif... it's ... inconsistent and terrible. Possibly a joke.

Some data: https://www.gwern.net/AB-testing#fonts

My own favorite programming fonts of choice at the time are either Liberation Mono (https://www.programmingfonts.org/#liberation) or Cousine (https://www.programmingfonts.org/#cousine) the latter of which builds upon the former.

They're delightfully boring, are readable at smaller sizes, have a good Unicode support, don't seem to have ligatures so i don't have to bother disabling them (personal preference) and are completely free. Plus they can be used to work with code that has large information density (think legacy Java apps) without causing strain on my eyes due to their simple look.

This is an aside but it makes it really difficult to me to enjoy when the site requires javascript to show me a typeface.

This is actually awesome, thank you for sharing!

This has got to be one of my least favourite trends in programming aesthetics these days. For a font claiming to "follow function" to devote so much effort to sacrificing function for the _vogue du jour_ is especially rich.

If you don't like them, don't use them. It's that simple.

Other people do like them, and will continue to use and enjoy them.

My understanding is that if the font has ligatures then the way to not use them is to use a different font (which is fine - there's a lot of fonts out there :) ).

Is that the only way, or is there a way to disable ligatures but keep the rest of the font? Can you disable only some of the ligatures?

TIA!

So you can turn them off even in fonts that have them, but most fonts have separate versions with and without anyway.

For Atom see (3).

There does not appear to be a way to disable them in Visual Studio.

(1) https://stacksjar.com/post/use-of-font-ligatures-in-vs-code

(2) https://marketplace.visualstudio.com/items?itemName=Coenraad...

(3) https://github.com/tonsky/FiraCode/issues/633

I sometimes—rarely happens thought—dislike how the cursor renders on top of ligatures in vscode. Always wished it would allow me to "inject" the cursor into the ligature, but since it didn't happen often or bother me as much, I never tried looking for a solution. This will be a small, but much appreciated quality of life improvement! Thanks again!

It's actually not that easy to use them with for example Emacs where you have to list every combination that you want to 'translate' to a ligature:

https://github.com/mickeynp/ligature.el

but you absolutely don't have to use them.

regular fonts are basically "use this image for 'a', this image for 'e'" etc. ligatures are extra data that says "if you find an 'a' next to an 'e', use this other image in place of the 'a' and 'e' images". but the non-ligature versions of characters are still in the font for use when there is no ligature sequence (just put a space in the middle of any ligature in your editor and you'll still see the independent characters rendered in the font).

Personally -- after originally thinking like you -- I really enjoy ligatures in my code. I disable them for my terminal though.

The same font can work both with and without ligatures, so it's not a negative if a font supports them. You can choose whether to enable them.

That is, I won't claim they help readability. But they do make me smile, and don't seem to hurt. (I'm assuming they disappear on copy operations. Mac OS' habit of replacing -- with a longer dash is painful when sending cli arguments.)

When I'm reading fiction, I generally don't mind ligatures. I find them oppressively obscurantist in any situation where I want to know clearly and distinctly what each character is -- i.e. code and science/math/engineering.

About the only time they are easily visible is in large type, when they really shouldn't be used.

It's kind of like right justified text. Done well, it shouldn't be noticed how it was done.

So, YMMV.

- there are more fonts without ligatures than there are fonts with ligatures. - every single OS I can think of include by default a monospace font that do not support ligatures. - there are still a huge amount of terminals which do not support them. - for almost any font that has ligature there is a variant without ligature - there is virtually no way to end up with ligatures without actively looking to get ligatures. - any terminal/editor that supports ligature has a setting for that. - most people do actually like ligatures which is the reason they use those editors/terminal/fonts and want those activated by default.

That's like your opinion man.

> So them parading ligatures as something desirable

Others desire them, so they include them. I thank that.

> shows that fonts' authors don't grok the character-oriented nature of computer languages

Nonsense, just an empty insult. I don't think you grok ligatures.

> only serves to detract from the rest of the font design

Your opinion, I believe it enhances the font design.

> to nick their credibility as coding font designers

Another empty insult. Including a feature that people like doesn't hurt their credibility.

See also:

https://www.dictionary.com/browse/subjective

https://www.dictionary.com/browse/opinion

https://www.dictionary.com/browse/aesthetic

Hogwash. They provided all the characters (which ligatures are also, but you seem bizarrely "against" but "for" the ASCII ones), and ligature-less versions as well. So they grok it at least that far.

In particular when doing presentations having fonts that are capable of producing ligatures in monospace contexts is quite useful.

You don't need to take their word or rely on their credibility for anything. There's a demo right there of the font for you to decide if it's for you or not.

I want to learn Julia in part because it makes use of “fancy” chatacters (so your math looks like math). I like the more functional JS style, and I’m interested in haskell. And I love ligatures. Anedata of one.

Are you more a C-family person, or an ML-family person?

I love them ligatures. I'm looking at this code for lots of hours every day. Let me enjoy it via a nice font — with ligatures — if I deem so.

Brain is really good in parallel processing of letters/symbols as units. I very much doubt that it's "objectively better". See https://docs.microsoft.com/en-us/typography/develop/word-rec... for overview of the research in this area.

For me the problem with ligatures is not so much of recognizing them but reproducing. I know that for arrow ligature I have to have = and >, but there may be ligatures that I might not be sure of how they're formed. Also, when reading the same code in different environment where the same font is not available I get different visual output where not only is the base shape of the letters different but code units as well. For example three lined equals ligature that some fonts produce. I really hate it.

Semantically, the language would like to use a ⇒, because it's representing the idea of an arrow. It's only due to keyboard constraints that it has use use =>. Parsers (and our brain is also a parser) would be much easier to implement if meaning didn't have to derive from symbol combinations like =>, !==, <!--. The input interface is limited to ascii to represent meaning, but our eyes don't need to be.

Sounds like we agree that a font that does this should never be a default. I don't think customized environments to the extent that one developer sees a different view of the code from another are a good idea (partly because I think reviewing and pair-programming are very valuable), but I guess if you want to set up something like that it's fine as long as you're not pushing it on anyone else.

> And any developer should already be well aware that no common language uses symbols beyond ASCII, so seeing ⇒ should be clear enough already that it's a ligature.

I've been using ⇒ in Scala for over a decade, shrug.

I wouldn’t know where to get the “⇒” codepoint, and getting is probably more effort than just writing “==>” with the added benefit of my teammates not having to use the ligature (or figure out the symbol) if they don’t want to either.

I totally understand the higher price for commercial use, here, it is cheap compared to the costs of hiring a designer, and it may have a real impact on your sales and ultimately earn you money.

But why is the price for personal use around $60? Is it some kind of a sweet spot because most people won't buy fonts anyways, even for $1, but those who do expect to pay that kind of money. Does it account for piracy, which I guess is easy and goes unnoticed if you only use it personally?

Luckily, everyone can get one at https://github.com/rbanffy/3270font.

Note: shameless plug ;-)

https://github.com/rbanffy/selectric-mode

I tried to switch back to another font and found that I was actually really enjoying MonoLisa... I ended up just spending the money since I felt a bit guilty staring at it for 8+ hours a day without paying the creators. Now, installing it is one of my first steps when setting up a new environment.

I guess if you find the current free offerings problematic then $55 is nothing for prolonged comfort if it does what it says on the tin.

For me i've always found the default in VSC on OSX to be really nice.

Tried ligatures once but it just became confusing tbh

It's just barely hitting the potential value where I'm willing to hit the download button, tacking on another $60 on top of that is just a complete non-starter for me. And trying to make money by shame (i.e. font makers deserve money) doesn't seem like it's viable long-term.

It is nothing rational, just a buyer's reaction to a product and its price.

In the US it might also be possible to protect a font design with a design patent, so even there you should be careful about assuming it’s safe to copy a font’s design…

Would be wonderful if they could charge 1/x cents per character used up until some fixed price point. but what an intrusive business model that would be.

If I was not down to pay for a font, then I'd probably use one of Iosevka's forms. Personally, however, it became clear to me that just like my monitor, the font I spend hours looking at every day is also worth some money.

https://fsd.it/shop/fonts/pragmatapro/

I like narrow fonts. Barlow is excellent. News Gothic is fantastic. Geo Grotesque is super beautiful. But it just doesn't work for me when a coding font is narrow. Fonts like Iosevka and Pragmata are harder to read than needed and for no clear benefit. Especially when used for projects based on C and derivatives. If you ever find yourself needing to cram more symbols per line onto your screen, it's a sign that there's a coding style problem! Lines simply should be short enough to not require horizontal compression.

Obviously, YMMV, to each their own, etc.

I like the narrower font so I can fit two side-by-side files with full 120 character width each on a regular 16:9 display. Iosevka is likely my forever font. I find it both beautiful and fit for purpose; I couldn't ask for more.

Re: "lines should be short." I prefer my code font to work even for bad code. It's not always my code that I'm looking at!

My takeaway is that monospaced fonts are basically a solved problem thanks to Iosevka. It does everything. And you can mix and match individual glyphs to your exact preferences!

It even has a Pragmata Pro Style.

[1] - https://typeof.net/Iosevka/

[2] - https://github.com/be5invis/Iosevka

One of their first points is this:

>Designing a monospace font is much harder than a traditional, proportional one: being constrained by the same width of all glyphs can result in a boring or unreadable font.

And they're absolutely right. But it begs the first-principals question-- why code using a monospace font? Today, every major editor that isn't terminal-based supports proportional width fonts beautifully. It's also incredibly rare to see modern style guides that depend on having consistent column widths. In 2022, there's no technical reason to code using monospaced fonts. And there are a ton of beautiful and readable fonts out there -- There are probably a dozen pre-installed on your system that are more beautiful and readable than this font.

You see this tag line time-and-time again. "A font designed by and for software developers." But font design is and art and a discipline. Doing it well is very hard.

Because unlike prose, we don’t reason about code in terms of words, sentences or paragraphs but rather in terms of statements, lines and blocks. Navigating between visual lines vertically makes sense when navigating in code. And to optimize this kind of navigation, monospace fonts are the best choice because where your cursor lands is predictible. It also brings cool features such as block selection which you can’t implement properly with proportional fonts.

There was a whole "coding font" family designed around the idea that we should be using proportional fonts for this, and it makes a great case...

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

...except that just about every time I've tried this, I've quickly run into places where trying to use a proportional font creates visual fails. Here's a simple one:

    /**
     * Render a given template
     *
     * @param string $_template
     * @param array $_args
     * @return string
     */

Proportional fonts in editors are a good idea whose time probably just hasn't yet come. We'd need (a) to have editors that support "elastic" or variable tabs to keep things aligned in a truly sane fashion, (b) to re-teach a generation or two of programmers that indenting with the tab character is good, actually, and (c) to develop a few new conventions for what makes code look neat and pretty.

That said, I don't see my lisp coffee caring that much. Let expressions benefit from lining up. Most other code, though? Not sure it matters that much.

> Put that in a non-proportional font, and the asterisks on the first line probably won't line up with the rest.

So lose the redundant asterisks. They serve no purpose. They make the comment both harder to read and harder to write.

At any rate, while you might be technically correct, in practice, "PHP and Java coders should abandon this long-held convention used by hundreds of thousands of programmers and decades' worth of tooling in order to avoid unsightly alignment issues when using proportional fonts in editors" may be a hard sell. :)

You quickly learn not to care about that. So what if the asterisks in the first boilerplate line don't line up with the ones below? And which of those two asterisks should have lined up with the others?

It just doesn't matter. Everything in the meat of the comment still lines up just fine in a proportional font, just as it does in monospace.

> Now think of someone doing visual alignment of assignment operators in a block of code like you often see in Ruby

I gave up that coding style many years ago, even before I switched to proportional fonts. You end up doing stuff like this (making up a contrived example, and not in any particular programming language here):

  name                  = user.name
  age                   = user.age
  driver_license_number = dl_database(user).dl_number

Maybe it is because I am getting older and all that sideways visual scanning is not as pleasant as it used to be. Maybe it is because of the unnecessary commit diffs that this style produces.

Once I stopped doing this, I realized that the code would look fine in any font, mono or proportional.

> or any code following the indentation standard where you line up parameters in a multi-line function header with the character after the open parenthesis like you often see in Python.

It's worth noting that Black, by far the most popular Python formatter, eschews column alignment in favor of a purely indentation-based format. Python code formatted with Black is just as readable in a proportional font as in monospaced.

Here is a more extreme example from Rust, whose rustfmt tool used to rely heavily on the kind of column alignment you're talking about:

    let mut rewrites = try_opt!(subexpr_list.iter()
                                            .rev()
                                            .map(|e| {
                                                rewrite_chain_expr(e,
                                                                   total_span,
                                                                   context,
                                                                   max_width,
                                                                   indent)
                                            })
                                            .collect::<Option<Vec<_>>>());

    let mut rewrites = try_opt!(
        subexpr_list
            .iter()
            .rev()
            .map( |e| {
                rewrite_chain_expr( e, total_span, context, max_width, indent )
            })
            .collect::<Option<Vec<_>>>()
    );

> re-teach a generation or two of programmers that indenting with the tab character is good, actually

Bless you for that! This is another advantage of indentation-only formatting. It stops mattering whether you use tabs or spaces! The code will be just as readable in any font, monospaced or proportional, and it won't matter at all if one dev prefers to render tabs as two spaces and another likes four.

The key to all of this is to abandon the kind of column alignment that monospaced fonts make so tempting.

I do agree with your point about Lisp. Monospaced fonts are so heavily ingrained in that culture that I couldn't begin to imagine how to change it.

There are some exceptions, of course. If you are writing out hard coded matrices, you may want to line up the numbers.

But how many of us really do that day to day?

Many modern formatters such as Black for Python and rustfmt for Rust avoid column alignment and prefer indentation instead. Then the code is equally easy to read and navigate in any font of choice, proportional or monospaced.

https://tosche.net/fonts/comic-code

To wit, Comic Sans is recommended by the British Dyslexia Association and the Dyslexia Association of Ireland. An American Institute of Graphic Arts post from last summer said that it might be the best font for dyslexics, given its "character disambiguation" and "variation in letter heights". While other fonts have been specifically designed to be read by people with dyslexia — Dyslexie and OpenDyslexic are two — they just don’t have the availability of Comic Sans. To hate on Comic Sans is “ableist", Hudgins argues, and doing so discounts the reading difficulties of millions of people.

https://www.thecut.com/2020/08/the-reason-comic-sans-is-a-pu...

MonoLisa seems to fall into a similar category. Is there a name for this style?

That said, the licensing seems completely out of touch from reality to me. Today we are living in the cloud area, where data and and workspace are replicated across devices. When I read that you need multiple licences to have it on more than 2 personal devices, that sounds too much of a hassle to consider buying it.

I don't think I ever had _a problem_ with a font, but that does not mean I do not want to spend a bit of time and effort to improve my experience. I could probably also get away with a much worse keyboard or monitor and be just as productive. But would I enjoy it just as much? Probably not.

Yes, there might be billions of free fonts out there, but the cost of that font is also not exactly making a huge impact for me that I have to save money there. Why would I start saving with the font all the sudden when I spend more money on literally everything else? Does not really compute to me.

I noticed that MonaLisa added script variant last year, so if you want something like that in your editor it’s a very good choice. In fact, I’d recommend it over Operator Mono (the OG monospaced font with scripted italics), because the later has a much smaller character set.

Or, pick a free Victor Mono if you like narrower symbols. Alas, us - wide font users - have to pay for a script italics :)

… where have YOU been spending time?

I think it increases readability. I need to read what I'm looking at, not a lot of things I'm not looking at.

"But then I can't see as many windows!" That brings us back to the GP's I need to see what I'm looking at, not what I'm not looking at". When you want to look at those other windows, bring them to the foreground and let them obscure this one.

I don't think that's enough of a reason to say the design choice is a sin for everyone.

This depends on your editor. I know VS Code supports indentation/alignment of wrapped words. I believe Emacs and Vim support it as well.

Another commenter replied that all editors have word wrap, but the resulting code doesn't look great, IMHO. I prefer full control.

https://fontlibrary.org/en/font/anka-coder-narrow

I don't see how "boring" is an issue here. If the whole thing has a goal of functionality, why do I care if it's boring? And what is a "boring" font anyway?

Reminds me of the Apple-induced desire to call everything "stunning" or "beautiful."

Exactly. Or actually, to go even further: On the contrary, "boring" may well be an issue, but in the sense that that's what we want. When you write code -- or prose, marketing copy, poetry, whatever -- what you want to concentrate on is the content of your text, not the esthetic of the letterforms. "Boring" is the opposite of "captures your attention", and if I want to focus my attention on the meaning of groups of letters, "boring" -- not grabbing my attention -- is exactly what I want the shapes of the letters themselves to be.

And yes, I want them all to be the same width, so I can line up repetitive bits of code (or poetry?) below each other and match -- catch -- the non-repetitive bits at a glance. (Sorry, we can't all write in bone-DRY functional languages; SQL is pretty damn verbose and often, yes, repetitive.) IMO that's part of the content I want to focus on.

Meanwhile, I look at new coding fonts on at least a monthly basis. Nothing beats Input Mono [^1] for me; I actually like wider fonts, so I might take this one out for a spin.

[^1]: https://input.djr.com/

I stopped hopping monospace fonts when I discovered Go Mono. Go Mono does not seem to get blurry even at small sizes. M, m, n always look impeccable. Not so here.

I'm not sure. Maybe something is wrong with the text-rendering in my browser.

https://www.programmingfonts.org/#go-mono

A serif monospace font that doesn't look it came from a typewriter? Very little separation between letters? A font made for specifically for typesetting one programming language? It really doesn't seem like it should work, but it does for me. I have it installed as the system monospace font on every computer I can.

After staring at MonoLisa in editors for 8+ hours a day for over a year, I can say that I _really_ love this font. Installing it is the first thing I do when setting up a new environment. It reads well in code and in the terminal, and I even wrote a significant amount of prose (60k+ words) in it and it was a pleasure. Definitely do not regret spending the money.

I can't find a font file called Monospace. Does anybody know what the font is? I would love to have it on my windows machine.

[1] https://sourcefoundry.org/hack/

I wish I was at home so I could post a screenshot.

A very ironic statement because I find the font to be absolutely unreadable.

Readability. Having text crammed into as little space as possible is efficient, but many people have problem reading it.

I guess I could have an unusual take on this, but I find a lot of mono fonts seem to have massive inter-line spacing. So much so that their appearance is almost jarring to me. I find it disruptive to read. If I had issues with the legibility of a font then I'd increase its size, not the spacing between lines.

As mentioned earlier though, I guess I'm an odd-one-out here, I'm seeking to understand how/why my view here is unusual.

Love the font

https://github.com/belluzj/fantasque-sans

I cannot look at text in this font without the feeling that every “g” is reaching out from the screen and slapping me in the eye.

21A7-depth

2334-counterbore

2335-countersink.

These are standard for hole annotations on CAD drawings.

Does the lowercase g follow that convention? It seems to make me almost stumble while reading and do a double take on what the letter is. But maybe it's just because I'm new to the font.

That font is terrible because its basically still ASCII only, but I use it everywhere. I would pay good money for a Unicode version.

> MonoLisa uses open forms and terminals (starting and ending points) that are pointing towards the neighboring letters to let the eye follow the line of text fluently.

Regardless, I like the font overall. My go-to is Fira Code but this might be worth a try.

(Or, also, that anything like what the site describes actually happens. The entire page is [citation needed].)

A quick search of hn shows the opposite: it seems like we're always talking about fonts and releasing fonts and comparing fonts. I practically have monospace font fatigue. But yeah this font looks nice enough

https://dtinth.github.io/comic-mono-font/

Though honestly, I'm mainly focused on the name. That's such a fantastic and clever name for a font and I can't get over it.

LOL

- Dejavu Sans Mono on the editor

- Ubuntu Mono on the terminal

Maybe it's just that Ubuntu renders such fonts beautifully, but any other font (except maybe Roboto) is an eyesore, to me

>CG

>Different terminals of capitals

Doesn't really work well for me.

I'm using Fira Code and it's only good for code. When I use it in the CLI everything looks off.

MonoLisa could solve this!