Nice but nothing will replace Iosevka for me now, the fact they have alternative glyphs for common programming usage and that you can rebuild the font to whichever set you want combined with extremely legibility at small sizes and a default condensed design (more characters per line for same width screen/window) makes it close to the perfect programming/terminal font imo.

Agreed. Coming from SourceCode Pro, everything seemed a bit taller, but adjusting the space between the lines fixed that perception. Looks smooth on my 2015 MBP, and external 24" 1920x1200 monitor.

My #2 is PragmataPro it still has nicer/more ligatures than iosevka but I expect that to get fixed over time.

It's a beautiful (but not free/open) font though.

Check out Hasklig: a fork of Source Code Pro with ligatures!

If you like Iosevka as much as I do, throw a few bucks the way of the creator via Patreon.

(I’m not affiliated, just a big fan of the font).

FWIW, the Input Mono family are the best coding and writing fonts I've found over the years, "Inconsolata" being a runner-up.

These days I use Input fonts in Emacs, all terminals, and writing apps like Ulysses, also on iOS. Nothing else comes close in terms of readability.

I found out about Consolas by way of Inconsolata.

One day I spent an afternoon looking for a better coding font.

I liked Inconsolata. When I Googled to find out more about it, I learned it is a knock-off of something that was hiding right under my very nose: Consolas found on Windows boxes.

I tried that and found it better. I now have Consolas all over the place. I'm typing in it on Firefox. I have it in Ubuntu right inside Gnome terminal and other places.

Thank you, Microsoft!

Agree! Conolas it's the best for me. And it's already there.

I agree! Fira Code and Input are my top choices, and Inconsolata / Ricty Diminished Discord are pretty close second.

I wish Input didn't remove ligatures from their latest release.

this is exactly right. condensed is my favorite, but there's no wrong answer.

Looks nice. Good thing they included stylistic alternatives for their default curly brackets, because that default would really bother me.

I don't like the weird proprietary licence though. There are plenty of excellent free software fonts out there (e.g., Hack or its ancestor Deja Vu Sans Mono and sibling Ubuntu Mono — all three exist today because of the permissive licensing of their common ancestor Bitstream Vera).

I've wanted a proportional font for coding for a long time! I sympathize with Rob Pike:

https://twitter.com/rob_pike/status/567476552187641856

I much prefer reading proportional fonts. This new font solves a problem I've had: punctuation is hard to discern in proportional fonts. But I'll still have trouble with deeply-nested functions not lining up.

I tried Input for a bit but wasn't really fond of the way it looked. My favorite coding font for some time has been Trebuchet MS. It looks really nice in the environment I use: fairly large fonts on a high-DPI display.

With one exception, it has easily distinguished punctuation and characters like 0Oo and 1lI|. The exception is that it has a rather poor tilde. One of these days I'll load it into a font editor and put in a better tilde.

Regarding deeply-nested functions not lining up, the solution there is to stop using column alignment and use indentation instead. As an example, the Rust team recently changed their style from this alignment-based format:

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

to this indentation-based format:

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

Even if you use a monospaced font, the latter style is much more practical. For example, if the arguments to `rewrite_chain_expr` were longer in length, you would simply change it to:

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

In the example in that stream of tweets, you have:

    put   = blah
    get   = blah
    post  = blah
    patch = blah

gofmt accepts it as aligned, but the equals signs are visually unaligned when using a proportional font.

I wonder what it would take to create an editing environment where you have a proportional font that shrinks or grows the (visual) whitespace to align those, and whether it could scale to things like nested functions.

Surely, one logical space of variable width is a tab? I prefer spaces to tabs - but if one makes concessions to readability like variable-width fonts - it's time to bring back tabs, too? (I do think this is a good idea, but "before" spaces won, in no small part because pre high-resolution screens, I think monospace was the better choice. With high dpi comes pretty layout - also of code).

The solution: Elastic Tabstops (http://nickgravgaard.com/elastic-tabstops/)

This is awesome - thank you!

For me the low DPI vs. high DPI displays didn't make a difference. I've been using proportional fonts ever since the days of very low DPI displays and still like them now that I only use high DPI displays.

The key to using proportional fonts is to stop using column alignment and use only indentation instead. There's an illustration of this in the rustfmt code I posted elsewhere in this thread.

And you're right, once you abandon column alignment, there's no longer any reason to prefer spaces over tabs, so you can take advantage of the other benefits of tabs.

The catch is, if I try to work with code relying on special stuff, and I don't have your special font, or special extension, etc. your code will look terrible.

Consider for any of these ideas (and the idea of various fonts) just how well it would work for the masses. Consider the mess if someone works on an open source project and checks in a bunch of code formatted for this.

Which is why I guess I'd see any kind of "fancy" spacing or even proportional fonts to be a real problem in an organization or structure where potentially many people, or new people over time, will have to work with the code.

What is really strange about this is that Rob Pike prefers proportional fonts, but gofmt mandates a column-aligned format that only works well with monospaced fonts.

This is one reason I don't use Go today. I am never going back to a column-aligned format that is hard to read in a proportional font, so I would have to avoid the use of gofmt, which would make me an outcast in the Go community.

I gave up on proportional fonts after a while. That was about 15 years ago, though... I think using clang-format and Comment Reflower/Emacs M-q/etc. would solve most of the problems I had with creating code that looked sensible when other people looked at it. If you've got the whole team layout out their code using tools like that, then the proportional font people won't find themselves having to line things up and whatnot.

Still doesn't solve the issue of having ASCII art diagrams in your comments. Though... the comment word wrap plugin I use for Visual Studio has markup to say that it should leave a section of the comment alone (I use this for ASCII art bits). And clang-format has similar directives for blocks of code that it should leave alone. Would be nice if text editors could recognise these (and other similar markup - or perhaps markup could even be standardized between tools?) and render the appropriate sections in a monospaced font. That might be a useful compromise.

Could you share the name of that comment word wrap extension? I use proportional fonts for all my code editing, but I would like a way to be able to switch a block of code within a file to monospaced - like you mentioned for ASCII art, or for matrices (the one place where I still would use column alignment).

This doesn't sound exactly like what that extension does, but it might be something good to look at to get some ideas. (Hopefully it's open source!)

Thanks!

No, it doesn't do anything like that - it just does word wrap. Comment Reflower: https://marketplace.visualstudio.com/items?itemName=codebeas... (page says it works up to VS2015, but I've got it in VS2017 too - so presumably it's forwards-compatible?)

One of its features is that you can pop comments sections in a <pre>...</pre> block to stop Comment Reflower doing anything to them. Here's an example, where you can see that the preformatted section extends past the wrap column.

    // Watford DDFS reads by initiating a multi-sector read,
    // counting sectors read, then doing this when it's got
    // the data it wants:
    //
    // <pre>
    // 0D43: ldy #$60                A=00 X=FF Y=60 S=DC P=nvdIzC (D=60)
    // 0D45: dey                     A=00 X=FF Y=5F S=DC P=nvdIzC (D=D0)
    // 0D46: bne $0D45               A=00 X=FF Y=5F S=DC P=nvdIzC (D=01)
    // 0D48: lda #$D0                A=D0 X=FF Y=00 S=DC P=NvdIzC (D=D0)
    // 0D4A: sta $FE84               A=D0 X=FF Y=00 S=DC P=NvdIzC (D=D0)
    // </pre>
    //
    // The loop at D43 is $5f*(2+3)+(2+2)=$1df=479 cycles, or
    // 240 usec.

So if you had a text editor that implemented my idea, the first and last paragraph would be in proportional type, and the disassembly bit in the middle would be shown in monospaced to preserve the formatting.

(In the long run, ideally, I suppose, you'd want your code text editor to support a wide range of formatting options, so that you could have italics and bold and monospaced and all sorts. But if you just decided that initially a simple proportional/monospaced font switch would be useful, this is the sort of markup you could use to key the transition off.)

Great, thank you very much!

Even if this doesn't do exactly what I'm looking for, it will definitely help give me some ideas on how to do what I want. It is indeed open source, and it looks like VS2017 support was added a few months ago:

https://github.com/kmunson/CommentReflowerVSIX

I would get pissed to shit trying to click between 'i's and 'l's when coding. Proportional fonts are for sequential writing, reading, and editing. They are designed to hide mistakes. The are designed to make all words have a similar texture. None of that is what I would would want a programming font to do.

Maybe it's familiarity but having just tried this (and Iosevka recommended elsewhere in the thread), I much prefer Consolas. Find it a lot easier on my eyes (this is with the Monokai-Cobalt theme on VSCode).

I tried switching all my UI fonts to Input recently, under Linux. Input Mono is pretty cool, but for whatever reason Input Sans and Input Serif have their kerning all messed up, making them very tiring to read.

At least Linux seems to handle the multitude of visual weights decently these days; when Input first came out it seemed like Linux would pick one weight as Regular and one as Bold and every other weight was mapped to one of those two.

Happy user of Input Mono ever since it came out back in 2014. Never looked back once!

Don't agree with there arguments about proportional fonts for coding though

I tried many programming fonts, and nothing so far was able to surpass the ergonomics of DejaVu Sans Mono.