1. 117
  1.  

    1. 23

      The interesting thing here is using several fonts in the same document. They show docstrings, TODO comments, and Copilot suggestions all being different fonts, which is cool and makes sense.

      It’s always interesting to see which ligatures are considered important. It’s gotta be based on what appear in the most-used languages, right? Like if TLA+ was more popular there might be a ligature to turn [] into , and if Prolog was more popular you’d see a :- ligature. So what language inspired ligatures for <~~ and :<? The ..< is for Rust, right?

      1. 25

        Ligatures aren’t important. You could argue it breaks intent for ligatures, is riddled with false positives, & confuses readers using your setup (in-person pairing, presentations/demos). If you want a , then type a .

        1. 11

          I love ligatures for general text, but for code, they break the “what you type is what you see” guarantee. It can be hard to make out the component letters of a ligature. Monaspace/s </ and /> ligatures are especially egregious.

          1. 2

            Right!? They look like some sort of Biblical hieroglyphics meant to represent the fetching and disbursing of water from a well.

        2. 11

          If you want a ⇒, then type a ⇒

          Most languages won’t accept in place of =>.

          1. 7

            Many of my favorites do. We should fix our languages so you can clearly mean what you mean as we haven’t been beholden to ASCII for a long while. Minus greater than, isn’t an arrow; is. How am I not supposed to think <= isn’t but actually means ? It’s a mess that APL had right.

            And when a language can’t support, I prefer Vim’s conceals to the representative character over the quagmire of ligature abuse.

            1. 19

              I’m pretty sure the Go, Python and JS maintainers would not accept a change to add a bunch of obscure unicode characters you can’t even type on most keyboards as operators. It’s a nice idea but just won’t happen in reality. Ligatures may not be “important” but they’re nice, I like them, not everyone does but I can do what I want with my editor, I can make it yellow comic sans if that helps me read it!

              1. 7

                Do you know how many keyboards don’t have a $ despite how many languages rely on it and honestly a lot of symbols not present on many keyboards? It’s an arbitrary line no matter how you slice it for what could or could not be considered keyboard-friendly and is hardly an “obscure” symbol when almost all of us learned it in math(s) class as ≤ before having approached needing it for progamming.

                1. 8

                  It’s not arbitrary. You could argue that the extensive use of a symbol only used in some cultures, the $, is a poor choice, but it was used because it was available on the keyboard of the language designers. =>, which I’m not gonna try to use the symbol for as I’m on my phone (and to not undermine my point), is not.

                2. 4

                  Strong argument for putting $ on every keyboard.

                  I was in the ligature camp for a little while… Ultimately what is important is that we are all working in the same language if we are working together. If you google around for “Chinese keyboard” you will see the $ right there where you expect (with a great selection of additional characters. If you want to add some more symbols to your programming, might I suggest starting with a few of those before you reach for some APL bs.)

                  It’s just one more accident of history, like so many others.

                  1. 3

                    With ฿ being the currency I use most regularly, I should invent a programming language that uses it to get it added to every keyboard. Would make my life easier.

                    1. 2

                      Just get a Thai keyboard…

                      1. 1

                        I modified my xkb layout. The point is that it’s arbitrary that we need to use a $ over a ฿. Why not use generic currency ¤ instead of $?

                        1. 2

                          Don’t ask me, Swedish keyboards have had ¤ since forever. In fact the first language I learned after Basic used it to denote strings, lol.

                3. 2

                  Yeah I get that, my keyboard doesn’t my own country’s symbol for currency on it, but I’m willing to bet many more keyboards in the world have a dollar sign on (which I’ve always felt is a weird token to use for languages and tools but that’s another topic)

                  Point stands, <= is pretty accessible, some obscure symbol isn’t. And I don’t think keyboard manufacturers are going to start adding all the math symbols! We’d end up with an emoji keyboard 😂

            2. 4

              Ah, but which arrow do you want? And how do you type it out? Do you need charmap open at all times just to edit code and hope you selected the correct glyph from the “arrow” search?

              1. 4

                Keyboard layers, Compose key, kitty terminal’s Unicode input, Vim’s digraphs, other editor macros… That’s a lot of freedom of options.

          2. 1

            i also don’t want a keyboard with 5000 keys on it.

            (maybe OLED keys somewhat fix this. there’s still a discoverability issue, though)

            1. 6

              If only there was a key that would allow you to compose multiple ASCII characters into one Unicode character.

          3. 1

            hopefully they do that later on, then.

        3. 10

          I wish there was a limit on citations of this article. Are there any others on the internet?

          Have you actually experienced in-person sharing and them being confused? I’ve used ligatures for who knows how many years, and I don’t remember someone experiencing that. The common experience is “oh this is cool, how do I get this?”.

          Whenever I see people on HN or Lobsters complaining about people liking ligatures, it reminds me of people saying that desire paths are wrong.

          1. 10

            I’m happy that ligatures exist and make people happy but I get thrown off when I’m pairing with someone who uses them. In languages I’m proficient in, ligatures conflict with the familiar structures I type. In language I’m unfamiliar with they obscure what I need to type to replicate a result. I spend most of a session like that mentally translating to the byte-representation I expect.

            I also find the transition to and from ligatures jarring and distracting when I’m watching someone edit code.

          2. 4

            Every presentation/talk I’ve ever went to where the writer didn’t consider the audience always had someone ask about it. Base symbols are the lingua franca.

            It’s often cited because it expresses many folks’ thoughts more consicely & from the authority of a typographer.

            1. 2

              ≤ has been the lingua franca for centuries, until a few people decided that <= is better and then everyone jumped on the bandwagon.

              1. 3

                But I don’t see the “≤” key on my keyboard.

                Getting serious now. Keyboards came from typewriters (d’uh!). If I’m using a typewriter, I can type a ‘<’, then hit backspace and type ‘_’ to get the ‘≤’ symbol. I could even hit the ‘=’ key, backspace, then ‘/’ to get ‘≠’. It’s unclear if the designers of ASCII (back in the 60s) deliberately wanted to emulate this behavior with the definition of BS (backspace, character 8). It’s definition doesn’t state that the previous character be erased, just the cursor moved back one space without erasing. I often think it would be nice if an editor (or system) could do this, and just know I realized that maybe this is what the ‘AltGr’ key (which, being an ignorant American, don’t have on my keyboard) does (even if conceptually).

                1. 2

                  I can hold < on my phone’s keyboard to get a . The touchscreen keyboards arguably make it even easier to add symbols assuming your keyboard is open source so you can fix the issues in it.

                2. 1

                  It’s Option-, on a Mac ;)

                  1. 2

                    Ah. While I do use a Mac, I use an IBM model M keyboard to prevent injuries and have Option (which is Alt) mapped to the Command key.

                    1. 1

                      I’ve never used any of the weirder characters that lurk beneath the Option and Shift keys on the Mac, I just know they’re there. Unfortunately every time I need to type °C I’m on another platform.

                      1. 1

                        I use ± fairly often and, if I’m entering anything non-English, the accent-modifier keys (option-i, option u, and so on) are great. I tried typing Étoilé on a Windows keyboard a couple of years ago and was amazed at how hard it is (on Mac, it’s option-e E t o i l option-e e). Oh, and I type dæmon if I’m feeling particularly smug.

        4. 3

          Agree that ligatures are awful. I have to get used to it and/or always second guess what the actual characters are that somebody has written on the screen.

          1. 2

            To be clear, ligatures as intended make it easier to read like fi, ffi, etc. but these never obscured the letters

            1. 6

              But with a fi ligature I can be reasonably sure that I and everybody else will read it as fi.

              With a ≠, it’s obscured and becomes a guess whether the computer is getting a =/= a != or a ≠ or something else entirely that I didn’t think of.

              1. 2

                Haskell uses /= and Lua uses ~= while OCaml uses <> and != (for structural vs. physical equality).

                I have a Neovim plugin that I’m hoping to smooth over all of these by concealing all language’s differing choice under the banner.

                1. 6

                  So, that’s literally what I hope would not happen.

                  1. 1

                    I find reading it clearer and easier to skim with conceal on than trying to remember each of these languages specific notions of these ASCII combos (while using the expected, basic math symbols I can use in those languages that do support ≠), the proper Unicode symbol is used so no looong equals or ambiguity issue, there are no false positives, & when working on a line the true input is always displayed (which sometimes helps jog my memory on how language X represent symbol Y.

                    Usually I’ll disable it for any long pairing sessions.

      2. 8

        The dedicated copilont font thing is even cooler than that: they propose leaving code produced by copilot in the different font, so you retain that information after the fact. Font family as metadata. It’s genius!

        1. 6

          I thought they were just saying that the current copilot suggestion would have the different font.

          I don’t follow how a text file could even store that metadata.

          1. 5

            Hey azeemba! As I read it, they are saying it as “this is a cool thing that becomes possible now”, because they really go out of the way to say “after the fact”:

            What if […] you could see which parts of your code it suggested after the fact?

            But it is in a section titled “What if” and you are right that it requires collaboration on the part of the code editor, so it’s not coming soon to a terminal near you. But it might be something for GitHub codespaces themselves, or the collaborative editor discussed at https://lobste.rs/s/s4mdxb/github_next_realtime_github .

            1. 1

              Thanks!

          2. 2

            There’s this thing called “rich text”, and file formats like RTF.

            1. 6

              Which programming languages are you using where the tooling accepts rich text files?

              1. 2

                It’s been about 20 years since I looked, but I seem to recall this being one of the early features of D. I can’t remember if it was RTF or HTML, but the idea was that you’d have rich text for comments and be able to embed images, cross-references, and so on directly in the source files. A lot of D has changed beyond all recognition back then, so they probably gave in to the tyranny of git diff.

              2. 1

                It wouldn’t need to; you could easily insert a preprocessor that converts RTF (or whatever) to plain text. (Vaguely similar to Knuth’s “weave” utility for literate programming.)

                I’m not necessarily arguing this is a good idea; just a thought experiment.

        2. 5

          Lookup “colorForth”

      3. 4

        ligatures in programming fonts i think got more popular with hasklig, then it branched out to other programming languages with unsavory effects. ones that don’t change the look of the original ascii drastically are not terrible, but they are still irritating to the eyes. In other cases they just plainly look nasty and draw attention, which is the opposite of what one wants. They are based on static rules and just guaranteed to be wrong in so many programming languages that it doesn’t make sense to ponder what ligatures are required, and where they are suitable.

      4. 1

        Pity that using multiple fonts for different document elements in VSCode is such a kludge. Requires a third party extension that must be re-enabled after every editor update.

        1. 1

          You should be able to style them through settings.json, no? I customize token styling and colors with semanticTokenColorCustomizations for example, I thought fontFamily would be supported there, too.

          1. 1

            Ruby doesn’t have semantic syntax highlighting so I’m using the editor.tokenColorCustomizations version, but it seems like foreground and fontStyle might be the only css attributes supported.

            1. 1

              Oh, that’s sad.

    2. 15

      Texture Healing looks amazing.

      1. 7

        It has also been done as “smart kerning” in https://commitmono.com

      2. 5

        I’m conflicted. It does looks really good, but your text is jumpy while you’re typing.

        1. 7

          It does look good, but it also looks like they cherry picked the examples. What happens in a word that has multiple m’s, but only one of them can be made bigger and the other can not because it’s neighbours are also wide? I can’t test it right now, but I expect it would look weird and uneven.

        2. 3

          The same is true for any proportional font that ligates “fi”, though

          1. 5

            It’s not, because the fi ligature doesn’t change the f, so both letters when typed appear in their final positions.

        3. 2

          Oh, that’s an interesting point. I have to try it some more, before I can say whether it would disturb me. But TBH, I’m not sure I actually look at the exact letters or words of my code when I type. I’ve just installed monaspace and will find out. (Though I’m not sure how to switch all those monaspace-toggles in e.g., vscode)

      3. 1

        yes, but i don’t understand why do they still want a fixed width font if the crammed latters are not good, why not just have proportional then?

        1. 3

          Because texture healing preserves alignment for stuff like ascii art.

          1. 2

            It messes with tables too. But I’ve been coding in a proportional font for 5 years now and I can count on one hand the times that alignment has been an actual problem.

            I still use monospace in the terminal because programs there like to print tables.

          2. 1

            ascii art shouldn’t be in code anyway, because it’s totally bad on screen readers, probably braillle too

    3. 12

      Tried it as my system UI and terminal font for a while. I had to go back to Iosevka.

      The contextual alternates for a more proportional feel is a great idea, but it seems quite limited at the moment. Example: iMi gets a wider M, but iÆi does not get a wider Æ, because it doesn’t seem to exist.

      It also looked inconsistent on my screen, rendering-wise, outright bad sometimes, and I don’t know why.

      I opened a feature request on Iosevka; maybe it’s easier to implement consistently in a font made from code, I don’t know.

      1. 8

        That’s probably the standard anglocentrism that we see so often, it’s not a letter they use, so they don’t care.

        1. 4

          You’re right that tech tends to be incredibly anglo- and eurocentric, but I don’t think they did it on purpose because they don’t care.

          My primary language is rarely supported by anything, so I try to think about that when I build a tool, but I mess things up anyway. Most recently I learned about ambiguous width characters. :)

          But with free software/fonts, at least we can help each other out with these things, and use our diversity to achieve better results. In the best case anyway.

          1. 2

            There’s probably also a case of optimising for the common case here. Each glyph that you do this for requires some tweaking. Most languages that use a Latin alphabet use m, w, i, j, and l. Some of them use ü, some use å, some use æ. So you focus your initial effort on the first set, then you work on the others later. And, if you’re lucky, someone native in a language with frequent use of Æ will be annoyed and contribute the improvements to make Æ work well.

            I would suspect that their initial version also doesn’t do a good job for the Greek and Cyrillic alphabets. Patches welcome, as the saying goes.

            1. 2

              Each glyph that you do this for requires some tweaking.

              For me, and probably most fonts, certainly.

              However, in true Iosevka fashion, the author has already added support for “texture healing”/variable width contextual alternates, all programmatically.

              1. 2

                iosevka is such a nice and pretty looking font as well :)

          2. 2

            Yeah, I might have been putting it a bit harshly there, let’s say it’s not something they come across, so it’s nothing they will work on optimise :)

      2. 4

        Iosevka is so perfect to me, I can’t imagine switching to anything else.

        1. 2

          The ability to customize it easily is a big selling point.

    4. 6

      Is it just me or is it really hard to tell the difference between having this enabled and having it disabled?

      1. 1

        For me it is easy on my external, high-DPI display, and harder on the little laptop display.

        As a user of letters that don’t compress well, like æ, I appreciate it.

    5. [Comment removed by author]

    6. 4

      This was recently implemented in Iosevka, and you can try it with a custom build.

      Interesting to see how it’s implemented in a font that’s created from code. This initial implementation was ready a few hours after I submitted the feature request.

      (If you build from source, and run out of memory like I did, try NODE_OPTIONS='--max-old-space-size=4096' npm run build -- contents::your-build-plan)

    7. 3

      Love to see typography better applied to code! It’s a shame terminal emulators tend to have such lackluster support (I know, I know, font rendering is hard), it’s not uncommon to find terminal emulators without support for bold fonts, let alone italics… Unfortunately given the limitations of the medium I don’t see things like dynamically switching typefaces or sizes happening in the middle of a document, but one can dream, I know emacs can do it…

    8. 2

      I’ve tried it, and it’s too wide for me. Even though it’s a variable width font, even in its narrower setting, it’s still wider than Menlo.

      1. 2

        Agree on that. I just tried it, and my go to is Source Code Pro on 13 size with font weight 400. Monaspace Neon isn’t as legible at 13 (for me, these things are of course also subjective), so I have to go up to 14 size and my VSCode take a lot more width.

        Hang on.

        If I compare: imi vs immi – it looks like Source Code Pro is also doing the “texture healing” thing. Is this maybe already a quite widely used trick in code fonts?

    9. 2

      I could not get these typefaces to work on Windows Terminal. The instructions seem to be Mac-centric, so I tried to install it on my Mac and that went better.

      Unfortunately, there’s a rendering bug in Terminal.app, where the last slash in the double slash URI separator overwrites the first character of the domain name. It could be a ligature issue but I cannot find a setting for it.

      Of all the “BigTech” typefaces from IBM, Intel, MSFT, Google and now GH, I actually prefer IntelOne, followed by Gofont Mono and IBM’s Plex.

      1. 2

        Plex is very nice. It’s nice to have a matching monospace and sans-serif pair of typefaces.

      2. 1

        Update: the typefaces are not presented as monospaced in Windows Terminal, you have to enable “all fonts” to reach them.

        The overwrite bug has been reported in the issue tracker. It seems limited to the “var” version of the typefaces.

    10. 2

      Even more fonts!

    11. 2

      And now I would want support for selecting font style in terminal emulator, tmux and CLI tools…

      I think it totally makes sense, there’s allegedly some functionality like that in xterm already. It could be useful in terminal text editors, shell auto-completions, starship and similar shell prompts, it could be used to remove hacks like patching fonts with nerdfonts …

      But it’s gong to be hard to convince these projects to give it a try, especially that it seems like nothing else will support it ATM to make it actually useful.

      Yes, there’s italics and bold already, but these … have a meaning and alter the font visually in very specific ways, while font styles could be used for very subtle changes that don’t affect readability/font weight as much.

      1. 7

        I’m not really convinced about the long-term usability of font-styles as information bearer in computer source code presented for humans. It’s different from existing presentations: normal/bold/italic, and colors.

        The latter can be derived from the code itself - comments can be in muted colors, or in italic, or both, keywords in bold or in a different color, etc.

        The former requires metadata not contained in the code itself to enable presentation. For example, you might want to have different font styles for comments provided by Copilot, and another for the ones provided by the user. If these are to be preserved across platforms, an entire new document format will have to created (“Rich Code”, in analogy with “Rich Text”). No doubt Microsoft is hard at work with this. I expect it to be an extension of Word’s current “HTML”, rife with embedded styles for different font variations.

        1. 1

          I don’t see anybody talking about inputting code in different styles. It’s for syntax highlighting. Having access to multiple fonts makes syntax highlighting better: in Xcode I use a serif font for doc-comments, for example.

          an entire new document format will have to created

          You mean like RTF, which has been around since the 1980s?

          1. 7

            You mean like RTF, which has been around since the 1980s?

            Have you ever implemented anything that had to deal with RTF? The problem is always which RTF. Apple and Microsoft standardised an RTF specification that includes specifying fonts and very little else. NeXT extended it with RTFD, which allows embedded objects stored in a bundle. Apple extended it with a load of things for specifying rulers, page size, and so on. Microsoft extended it for dumping a load of random attributes from Word’s in-memory representation.

            Interoperability between things that produce RTF and consume RTF is very hard, unless both of them use NSText (Windows, of course, doesn’t have a library for producing and consuming RTF, it has a bunch of things that all support different extensions to RTF).

            1. 2

              I did, actually. My first paid work after college (in 1987) was a contract job building a tool to convert docs from some proprietary phototypesetter markup language into PageMaker documents. PageMaker’s file format was pretty impenetrable, but once I discovered RTF it wasn’t hard to convert the markup into it, and PM could import RTF.

              Even back then it supported more than just fonts. You could specify pretty much all the ruler & paragraph attributes supported by Word 3, and I think there was a tag to insert an external image file.

          2. 1

            The thing is, I can download code you have written from a repo, and exactly reproduce your Xcode settings, and get the same appearance of the code you have. Or I can change it to suit my tastes. The appearance is derived from the UTF-8 sequence of characters that is the source code listing, but it is not part of it.

            With a hypothetical “Rich Code Format”, that would be baked in. The actual source code would be an unreadable mess (even if it was all UTF-8), and you would need specialized editors to load and read it. All that stuff would have to be stripped out before a computer could ingest the code and act on it. And if you didn’t like the way the code looked, you’d be shit out of luck, or ignite the Mother of all Code Formatting Battles.

            (Although… I can kind of see something like MIME-encoded email, where you have both the plain text and a “rich” representation… vade retro, satana!)

            1. 2

              This is all true. I don’t actually think it would be a good idea for text styles to have meaning in code!

    12. 2

      Alternately, you can just program in a variable width font. It works fine! At least in Python and Go and C. I’ve got an elaborate setup for this, mostly Python. Once you commit to a code formatter like yapf or black the rest is pretty easy.

      1. 3

        A proportional font means that you can’t predict where your cursor will end up when going up/down.

      2. 2

        The problem with using variable width fonts (like using nonstandard tab widths) is that it messes up the alignment of hanging comments. The best solution to this problem is elastic tab stops which has been around since 2006 but has never been widely-implemented enough to become popular.

        1. 2

          You’re right about hanging comments. I never used them much and don’t miss them, but it is a limitation.

          Elastic tab stops are a nice solution! Shame there’s no solution for VS.Code, see this bug report. (There is a plugin but it only works with monospace fonts.)

        2. 1

          that’s one of the reason i use one - less space and broken alignment helps me to see which line is a comment hanging on

    13. 1

      I’ve often wanted different fonts for different textual roles, but since I’ve settled on a text editor from the 1970s as my main interface for coding, odds are poor I’ll end up getting that :D

      Still, I kinda love the texture healing feature; I wonder how I’d feel about it in practice?

    14. 1

      I started to read this site. But every 5 mins the site crashes with message “aw, snap” in my google chrome. And I have to refresh the site to continue reading. This is one of the few sites where I see this effect.

      I have a lot of tabs opened, maybe that is the reason. Also I use old version of Chrome (103.0.5060.53). Or maybe the site is buggy. Or it consumes too much memory. Should I report this to site authors?

      1. 3

        You should update chrome, you have bunch of critical CVEs with that version, including the recently discovered webp exploitable ones I believe. If the error still occurs and it’s just memory related I wouldn’t report it, otherwise maybe.

        1. 1

          Thanks! Unfortunately, I use old debian stretch. I tried to install recent versions of chrome and failed, it seems they are unsupported

    15. 1

      I like the idea of this font family a lot. I really like having a set of related fonts that are made to be used together, though Input and Iosevka both already scratch that itch.

      I also really like the idea of textural healing, though support for it seems to be pretty spotty in applications and platforms. It looks like it works (specifically enableable and tunable) in VS Code on MacOS and Windows; bug reports suggest maybe not in VS Code on Linux. It seems to work accidentally (?) in Visual Studio (Windows). I have been banging my head against Freetype settings and Pango font selector strings trying to get it to work in Emacs pgtk on Wayland, but it doesn’t seem to be working, even though other OpenType font features like ligatures do.

      I hope they get this working everywhere. It would also be nice to see a matching variable-pitch sans-serif.

    16. 1

      The point of “texture healing” is not to get an equal space average between each letter over a word. It’s to make m and w have more width when they can.

      1. 1

        That’s what happens here, except that “when they can” is decided automatically with a word-wide context.

        “Divide by word length to get an average, and now we have a scaling factor for each cell in this word.” is phrased somewhat unclearly: there’s a different scaling factor for each glyph, m (120% of the cell width in that word) being wider than s (100%), which is wider than i (80%), but they’re averaging out over the length of a word.

        1. 1

          Right. So the extra space is apportioned depending on that factor.