Coding ligatures

[astrolemonade]

Lots of programming fonts support ligatures, something that wasn't a thing when Gintronic started. Today they improve readability a lot and sometimes help at saving screen width.

(image took from FiraCode repo ) There are more to be discussed but these are the minimum minimorum.
The above picture shows some important ligatures that one programming font should support for better coding experience.
As a workaround, you can add ligatures to the font from FiraCode(using https://github.com/ToxicFrog/Ligaturizer) which transfers some of the ligatures to Gintronic. The big issue is that they feel a little bit out of place and blurry sometimes!

[Mark2Mark]

Thanks for the links and input. I will have a look.

@cata0309 do you also happen to have some dummy code snippets which use as many of those ligatures as possible? When I design them, I need to see them in proper context. The overview from above is super helpful, but the context would be top notch.

Also which code editors do you use? Gintronic was mainly targeted into Sublime Text, Atom, Xcode and Mac Terminal back then. Currently I also use VS occasionally.

[Mark2Mark]

The multiply sign in the Hexadecimal Ex is weird: it’s not a multiply but should be an x in 0xFF

[Mark2Mark]

The equal signs are very debatable. In some programming languages it might be preferred as you see in the Ligatures On examples, but many programmers want to see for instance != or == as exactly those 2 characters they typed.

[astrolemonade]

[Mark2Mark]

Can you elaborate and not just post screenshots please? I don’t know what those are about.

Also for the code snippets: I’d need them as text, not as images. Thank you!

[astrolemonade]

I can't know all the ligatures use case but you can try testing programming fonts with ligatures on this website:
https://www.programmingfonts.org/ Choose somethink like JetBrainsMono/Iosevka etc

[mariojackson]

Hi @Mark2Mark

I'm thinking about buying the font. I like its uniqueness and style.

However, the font has its price and before buying it, I'd like to know if ligatures are planned. I would buy it in an instant if ligatures were being added in the future. Otherwise, I would have a hard time, since many other programming fonts which are cheaper, have ligatures.

Can you tell me whether ligatures are planned?

Thanks in advance!

[Mark2Mark]

Hi @mariojackson

Thanks for your request.
During latest developments it seems that I wont be likely to add new features to Gintronic as it is. Only bugfixing. However I am working on the predecessor of Gintronic which I will release with my own foundry Hypertype soon. I am also considering to add ligatures for that one, even though I am a great disadvocat of coding ligatures myself. But I see there are user’s who wants them, so I’ll probably go the extra mile and add them there. I really respect your and other’s request, but also want to mke sure that you don’t buy anything in the hope to get features that does not yet claim to have. When the predecessor has ligatures, I’ll also advertise those as being included.
Update: I am currently working on version 2.0 of Gintronic, which will include a set of coding ligatures. The current development can be followed here.

I’d be curious:

• Which editors and on which platfrom(s) are you programming?
• Is it okay if ligatures are optional, are those toggle-able in your IDEs?
• Are there more important ligatures than others? Or is is a all or nothing?
• Are there certain levels of ligatures? E.g. the == should not be connected in my eyes, it’s changing the semantics too much. However, other ligatures are very plausible, so maybe there should be a way to to go gradually from no ligas over some ligasall the way to everything-ligas?

[mariojackson]

Hi @Mark2Mark

Thank you for your fast reply. I totally understand that ligatures are not for everybody and that it's more subjective. Thank you for being honest, I'll wait for your predecessor in this case. Do you already know around which time it will come out?

• I'm mostly using JetBrains IDE's, VS Code, and Vim on macOS and Linux.
• It is totally ok of course, if ligatures are optional. I would even prefer it.
• I don't have to have all ligatures personally. I'm totally ok if == is not connected. I like simple and decent ligatures, in cases where they'd reduce clutter like having
  instead of --> -> -->>
• I think it's a good idea. I don't like all ligatures, too. Especially not if they make things harder to read (like ==, === or www). So something gradually would be great, to satisfy most users imo.

[Mark2Mark]

Hi @mariojackson,

Thanks for you input, that’s very helpful.
I hope the release can be early ’22. We’re working with pressure on it.

I guess it would be reasonable to make some sort of list of ligatures and then mark those that are relevant and kick out others that are too much. I don’t even have a proper supervision of which ligatures can/should exist, as I am not working with too many programming languages or syntaxes. For me it is: Objective-C, C, Swift, Python, Java, JavaScript, PHP, CSS, HTML, markdown, shell and so on, but no Haskell, Closure, or Ruby or Go etc, where ligas might come in handy more, I guess.

[effinsky]

Is there a place catch a glimpse of the new monospace font?

[Mark2Mark]

Not at this very moment. But I hope soon.

[astrolemonade]

Looking forward to seeing the progress on the new monospace font too.

[Mark2Mark]

Thanks, Cons-Cat. I know what stylistic sets are ;)

BTW: onum, zero etc are not stylistic sets, but also separate OpenType-Features. Gintronic has similar things for the numbers, just that it is a lining number feature to turn on as the onums are default in this design.

My quoted question was not about the technical implementations of how those ligatures are made (I am well aware of that), but the differentiation of which ligatures should be forced and which should be added in a granular fashion by the user optionally.

[kkirsche]

Apologies if this feedback isn't useful, but wanted to throw my feedback in should it be of value.

• Which editors and on which platfrom(s) are you programming?

I use VS Code primarily with Neovim as a fallback.

• Is it okay if ligatures are optional, are those toggle-able in your IDEs?

Yes, they are. I learned how to do so via a different font, MonoLisa. See https://www.monolisa.dev/faq#how-to-enable-alternate-zero-stylistic-sets-and-the-script-variant for how they solve this problem (from the editor side, not the font itself).

• Are there more important ligatures than others? Or is is a all or nothing?

In my opinion, the most important ligatures are ones that address visual kerning, such as ++ and ??, and ones that are meant to act as "shapes" such as -> and =>. It's not all or nothing for me, and as long as they cover the most common use cases, I don't think it's a big deal.

• Are there certain levels of ligatures? E.g. the == should not be connected in my eyes, it’s changing the semantics too much. However, other ligatures are very plausible, so maybe there should be a way to to go gradually from no ligas over some ligasall the way to everything-ligas?

This is achievable, but I don't know technically how it's implemented by other fonts. I view it from a category mindset, such as equality could enable !=, ==, >=, etc., arrows may enable ->, =>, <=, <-, etc.

Thanks for all of your time and work. I greatly appreciate all you have done for Gintronic and love it as my terminal typeface.

[Mark2Mark]

Thank you, @kkirsche

Regarding the font features: Funny, I just added this today

The different levels could be implemented via different stylistic sets. So maybe ss01 only enables ==, ??, →, => and ss02 enables more "advanced/unusal" ligatures, etc.

Many thanks for all your input. I will take it all into account.
Glad that you like Gintronic. I will soon send out an update with some minor fixes as well as the narrower spacing as the default now (some IDE’s or terminals ignored that, so some users didn’t even see it. But in other IDE’s it turned out to look too much spaced appart.

[effinsky]

speaking of... there's narrower spacing? please link to how one enables that and/or to some examples of what that looks like. thanks!

[Mark2Mark]

It is coming very soon. I’ll send it out once it’s ready. It will be new font files to be replaced with the former ones.

[Mark2Mark]

A little note about my current planning/thinking:

In recent times, IDEs made it more feasible to turn on certain OpenType features (see a growing collection of how to here), which usually allow for a more granular control over the alternatives selection.

So I will be trying to direct different sets of ligatures into stylistic sets, where the default (all sets off) will be no ligatures at all; set 1 will have some very common ligas; set 2 will have those, plus more less common ones; and so on. I still need to figure out which will go where.

Another new feature I will implement is contextual GPOS, which allows to move glyphs around in a certain context. This will allow for improved readability without ligatures. For example in foo::bar the two colons can move closer together to appear more as a union.

[zygous]

I've been using Cartograph for quite a while now (although I've just switched to Gintronic), and quickly came to really like the connected ==, the slashed != and the triple-bar connected versions of === and !== (which are heavily used in JavaScript and TypeScript). In practice, there's no confusion between a double-width, connected == and a shorter = for assignment.

The other things that I've enjoyed are proper arrows, e.g. ->, =>, which improve legibility greatly. Ruby uses ~> arrows in Gemfiles, and it's nice to see those as proper arrows too (Mono Lisa has this, but Cartograph does not).

The greater-than-or-equal-to operator is nicer to read when rendered as the symbol it's supposed to mimic >=. This does lead to a potential conflict for less-than-or-equal-to and left fat arrow: <=. In my coding, I've never needed to use a left fat arrow though, so I'd prioritise a ligature for less-than-or-equal-to (I guess this could be overridden with an OpenType feature though).

Other than a those few key ligatures, I think the contextual GPOS would deal with all the other cases I've found are a nice touch, e.g. slightly closer ::.

TL;DR: The ligatures I'd most like to see are for ->, <-, ~>, =>, <=, >=, <=>, ==, ===, !=, !==. I think that would cover most cases for me using the following languages:

• JavaScript/TypeScript
• PHP
• Ruby
• Rust
• Java
• Bash

(BTW, I mostly use Neovim in Kitty on a Mac. Kitty supports ligatures (obviously) and specifying OpenType font features per-font.)

[Mark2Mark]

Thanks for your input!

This looks like a good list to use as a start for the implementation. Seems a nice set for the first level of ligature-ness.

As I plan to disable ligatures by default, I can just ship updates with these without breaking backwards compatibility. Hoping for you users to help testing and improving. Coding ligatures are hard to test IRL by one person, as they are subjectively to be judged. So I can try that democratic approach 👾

[zygous]

Sounds ideal! Thanks Mark 🙌🏻