Hacker News Reader

Comment by nkrisc | Hacker News Reader

I was disappointed that despite presenting the cookie banner as if it were a terminal, the options did not accept keyboard input

    [Y]es, I agree    [N]o, thanks

Ok on topic: I'm never sure what to think of these "developer" fonts that make use of ligatures for combinations like ==, >=, ->, =>, etc. On one hand they do look really nice, but I always can't help but feel it would actually make things just a little bit harder to scan and parse quickly.

I do find it a very pleasing font to read, however.

View on HN

With a good deal of skepticism, I switched the environment where I do about half of my work to a font with ligatures some time ago. Just to try it out for a while.

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.

For some reason, I just don't like the spacing in Fira Code... I really like Inconsolata/Consolas myself... I've tried both, but it just feels off to me.

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.

Wow, I didn't think I wanted ligatures and so I never turned them on. But based on your comment, I just tried it and I found that I love it! The little visual blip! when the characters merge does in fact provide a nice little feedback that I've typed the right thing.

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.

Same. Any font that claims to be for programming but includes ligatures gets a "no thanks" from me accompanied by a bit of sadness because they often mar otherwise nicely designed typefaces.

You really don’t have to use the ligatures, do you?

I don't know about other programs, but iTerm has a checkbox option to enable/disable ligatures.

So does JetBrains IDE's and VS Code. I don't know of any program that forces you to use ligatures just because the typeface supports it.

Visual Studio (the full blown IDE)

Add to settings.json:

    "editor.fontLigatures": false

(Edit: sorry, just realised you were talking about the full blown Visual Studio, not VSCode)

You don't; there's a checkbox to toggle them, and it defaults to 'off'.

For me it is the reverse, I only want ligatures now and feel a programming font isn’t done until it supports them.

As I know, VSCode, Iterm2, Jetbrains IDEs have ligatures option that we can turn on/off easily.

Does anyone know how to turn off ligatures in XCode?

I do love the ligatures in Fira Code. It always makes me happy to see the nice looking <=, >=, !=, !== or ->.

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 a little ambiguous to me. For example, the ligature for #{ looks like it could be #={. I honestly couldn't tell until I selected the text.

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.

Also === in JS and TS turning into three horizontal lines is really nice for my brain (even though lint catches it). Fira coda retina is still my go-to font, this one doesn't look quite as legible.

I agree about ligatures. I use them whenever I can because they look cool, but sometimes I think it actually is to my detriment. For example, if I mistakenly type `->` it looks very similar to a ligatured `-->`.

I've just installed this font and tested it with VS Code, and I must say that it is a very nice font. Code is clear and easy to read (C/C++ development). I think I'll keep it for a while.

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

This is why I love how configurable editors are now days.

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.

I'd much rather see languages take advantage of characters outside of ASCII. There are already symbols such as ⇒ which could be used by a language.

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

That seems like it would be difficult to type.

What's stopping editors to provide shortcuts akin to ligatures? Eg. typing "=>" would make use of the "follows" sign.

And now you can only type code in the set of blessed editors and correctly displaying fonts. "Make code pretty" should be a matter of presentation, not 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?!).

In general, I agree with the principle: presentation and source code are not tied together. But we've been constrained to ASCII for programming for far too long. Sure, there are benefits, but is there a way forward? How can we know if we don't explore it.

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

Sure, it's possible, with major compat breaks. What I'm asking is this: what is the (commensurate) benefit from this change? I just don't see "looks prettier by default" as a strong enough reason - what am I missing?

Unicode and its transformation formats (UTF-8, -16) were major "compat breaks", and to be honest, still are. We did not push for them for the emojis, but for the ability to be more precise and more expressive.

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.

Quite the contrary, UTF-8 is backward compatible to ASCII...it was a compat break from the local character encodings.

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

Sure, UTF-8 is backwards compatible with ASCII, but as you figured out, I was referring to all the 8bit encodings that were in widespread use (eg. HTTP defaults to ISO-8859-1/latin1). And even with "pure" 7-bit ASCII, there is still no reliable way to send an email to неко@негде.срб. You may believe that there are no compatibility problems, but I disagree.

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

That's...a terrible idea. You're now bound to a specific subset of editors that are capable of producing ⇒ (as opposed to the two-character => ), for...for what?

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.

I love ligatures, I now have all my IDEs set to use FiraCode, it works especially well with Clojure IMO.

I must be getting old <g/> ligatures:false all the way at this point...

It accepts keyboard input, but you have to click on the terminal first.

Then shame on them for not focusing it by default.

I'll be honest I can imagine it's on risky legal ground. A stray y key hit when doing anything on the page accepts the agreement? For all their faults, all other implementations are much more explicit and resilient than this, as they require a targeted click.

> they require a targeted click

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

Comment characters, and compound operators without ligatures, are ground glass in my eyes.

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.

Anything printed or displayed in that font will confuse people unfamiliar with that font's ligature system as well. I say thee nay!

Agree about ligatures too. Many of those are pretty unpleasing to read (AKA typographically wrong), e. g. /=.

I've been using ligatures (Fira) for about 4 months now and love it.

Emacs has a minor mode (prettify-symbols-mode, I think) that makes substitutions like these. I tried it for a couple of months, but decided that it wasn't for me.

I've recently tried Emacs for a few weeks and prettify-symbols-mode doesn't look nearly as good in my opinion, as the scale and style of the symbols isn't consistent with the font. Also I never got any symbol out of it in any situation except an arrow and lambda.

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

It is possible to take this too far.. https://imgur.com/a/5NP6FWx

But it did keep me entertained for a bit.

Yup, also don't like ligatures. They're a solution looking for a problem. Will however try this font when it drops in IDE updates.

Reply on news.ycombinator.com