I happily forgot that I had done it as a trial, and upon reading this headline caught myself hoping that there would be ligatures.

I actually find that it provides an almost haptic feedback when going between things like =, == and ===, and I think I miss it just a little when I don't have it.

As for the font itself, I like it but slightly prefer the style of Fira Code.

And also the two-character => arrow in fat-arrow functions always kind of bugged me a little bit and it is nice to have it condensed to a single visual entity.

Woo hoo! I will leave ligatures on from now on.

Aside: Hopefully this font has box and line art characters and they align properly... this is a huge short coming in a number of fixed-width fonts that should be rectified.

    "editor.fontLigatures": false

I am not so sure about these, though. Maybe a tad to much/to special in some cases? Somehow they don't pop for me the same way.

Some of them are nice, however. Specifically the ones that just tighten up the spacing and make small adjustments. For example, most of the ones that involve a colon I think are an improvement, but still distinct and unambiguous.

Regarding ligatures, I agree. I could live with the pointer arrow ligature, that's fine and looks nice, but not with the crossed '=' (that is "!=") or the symbol for >=. Call it ageing, but for the moment it stops my code reading flow. So "editor.fontLigatures": false

I absolutely adore ligatures in my programming fonts. I've been using FiraCode for at least a year or 2 now, and while i'll be the first to admit that the reason I enabled ligatures was because they looked cool, now I really miss them when they aren't there.

This is a nice feature of APL, and the derivatives such as J which use plain ASCII are much less nice to work with.

For looking pretty, I assume: that's probably a matter of UI (editor displays arrow character instead of equals+greaterThan), but should not propagate into actual source code.

To use your example, typing "=>" could display the "follows" sign, but the string representation should not depend on exotic characters like "ř", "⸙", or "" (is that a box symbol, or "symbol not found in current font"? Oh wait, the HTML input field ate it! See?!).

Most development IDEs are configurable and extendable in such a way. Or well, at least the one I am using is (Emacs). Just like opinionated languages have not had those choices stop them from becoming widespread (eg Python re indentation), so shouldn't the character set used either.

You could also redefine your keyboard layout (eg. a happy hacking keyboard has no marks on the keyboard) or come up with a programming input method (IM) to use — not everyone would have to do it, someone would make it and others would use it. But making wider use of the characters available has to start somewhere, and it can't start with input systems (before there's a widespread need for them).

Mathematics has developed a very large alphabet for the very same reasons, and if it was constrained to ASCII, we'd be learning integrals today in the "Newtonian way".

If you don't see those properties as offering any benefits to a craft that is based on precision and that has new languages popping up regularly to cater to new expression forms, that's fine. I still believe it's an unexplored area, and we'll only see benefits once we start to make heavy use of the advances.

As to mathematics: do you imply that using a wider charset is akin to completely new mathematical methods? Or that a symbol needs to be one character? Both sounds implausible, I still must be misunderstanding...

As for maths, I was referring to the fact that notation (signs we express ourselves in in writing) matters, and that further advances in calculus were enabled by using a nicer and more concise character set vs doing everything with "fluxions" and "fluents". You seem to insist on keeping us restricted to ASCII, whereas I am open to exploring new approaches without understanding if there are any benefits first (I am not focused in RoI :)).

As opposed to a targeted key press?

Seriously, what's the difference? It's very common for GUIs, and even TUIs, to accept key presses for actions

The first thing I checked for here was ligatures; this font would not have gotten five seconds of my time otherwise.

If one doesn't want ligatures, one turns them off. No one should design a programming font in 2020 without ligatures, just like no one should design a programming language in 2020 without a language server to handle editor services.

In a language like Haskell with many compound operators, the code just looks stupid and irritating without ligatures.

I may be at one extreme here, for I absolutely loathe comment characters. I've programmed preprocessors for each language that I use, with defaults that flush left is a comment (to be appropriately syntax colored, and with a convention for blocks that include indentation) and indented is code.

But it did keep me entertained for a bit.

I'd much prefer if Emacs just supported actual ligatures.