Hasklig style ligatures

[i-am-the-slime]

This'd be so cool:
https://github.com/i-tu/Hasklig

[metaskills]

Agreed, was the first thing I looked for in this project.

[GauthierPLM]

I'm looking for that too. But not only for Haskell related ligatures (a big part of Hasklig ligatures are Haskell specifics), but for more general programming ligatures as available in FiraCode who have a lot of ligatures available, and a big part of them are common programming symbols.

[chrissimpkins]

For those who aren't aware of ligatures in source code typefaces, see the Fira Code site which has a nice set of images that show the ligatures compared to the actual glyph combinations.

I have been torn on the standard ligature issue. While it works very well in circumstances when you are working in an editor with the typeface and know that the ligatures are present, it misinforms readers when the typeface is used to display source code to others (print, websites, presentations, embedded in pdf's, embedded in applications). You can imagine a scenario where a developer who is new to a language attempts to use a Unicode leftwards arrow ← rather than a < adjacent to a - because that is the way that it was displayed in the location where they learned it. In these cases, the type interferes with the message. IMO, this limits the scope of a font with standard source code idiom/char combination ligatures and my goal is to maintain the main branch of Hack as a general use face for source (including display and embedding).

The OpenType discretionary ligature feature (off by default, explicitly activated) would be ideal, but it isn't supported by any desktop source code editor to my knowledge so it would not address your request. On the web side, the CSS3 spec includes support for them, but I do not believe that this is widely supported by browsers at the moment either. This does not appear to be a good approach for now.

This would be a great feature for a working font designed for a select group of developers and I think it would warrant a separate build from the general purpose main branch of Hack to support it.

My understanding from the Fira Code and Hasklig documentation is that standard ligature support is spotty at best across current versions of commonly used text editors. I guess this begs the question whether this is worth the effort until that situation changes.

[GauthierPLM]

For editors in Java (like IntelliJ), the OpenJDK have a bug who prevents from rendering ligatures. An issue on the JetBrains bug tracker (https://youtrack.jetbrains.com/issue/IDEA-127539) have been opened to support ligatures into the IDE and a guy from JetBrains has reported the bug to the JDK team.
If it's solved, we can hope that IntelliJ and others IDE in Java should support Ligature.

Currently, I only know 3 OS fonts who provide ligatures for coding + Pragma Pro. It could be a good feature in your font, especially because it's a coding font. Having a separated branch is a good idea or the possibility to customize the font (as with Monoid) could be a good idea, with a warning to suggest users to not use ligatures in their articles.

[alerque]

@chrissimpkins I agree pretty much tit for tat with your analysis here. This can be great for somebody that know exactly what was going on but is a probable source of trouble for anybody unfamiliar with both the programming language and the font features involved. In other worse it would be nice to have but only in the context of an off-by-default feature.

The only thing I can really add is that browser support for CSS3 features that enable alternate ligature sets and other OpenType features is actually pretty broad already and can be used in most scenarios. That's a viable way of providing the feature not only on the web but in a lot of editors that are browser based. Some of them are buggy at the moment but I don't think it will be long before accessing alternate ligatures is viable in a lot of editors.

Terminal based editors (where I live) are another matter. It might take a second version of the font to make that viable at all.

[lozandier]

I also agree with the original poster of this issue for ligatures to be supported.

Regarding the thread about the usefulness of ligatures @chrissimpkins @alerque has started, ligatures are a no brainer to have on by default as ligature by definition enables *monospace *typeface to better communicate the intent of two or more characters than they could by themselves. In the context of code, enable better understanding of the intent of the code

Being a monospace font, editors that can't support them should have no problem having Hack being used like any monospace font.

In other words, they gracefully degrade. It shouldn't be "off" (efforts that deliberately not allow the ligatures to be used out-of-the-box like any other Openttype typeface) as it would break the principle of least surprise as far as the OS. Editor's often by convention make it a opt-in feature since the developers of editor's may find it worthwhile to accommodate users of a non-monospace typeface that may

It's more of a matter of a serious effort be made, more than anything else. If ligatures of a monospace typeface makes the intent of a set of characters in the fixed-width space they occupy more confusing for development (it's a monospace typeface after all), then that typeface has failed the users of that typeface.

This feature is extremely important for languages that encourage or enable functional or async programming paradigms as needed for applications often such as Haskell, Swift, Go (esp. CSP), JavaScript, & etc.

In 2015, it should increasingly be the norm.

[alerque]

I'm sorry @lozandier but I don't buy that line of reasoning. Here's why.

First, OpenType ligatures being off by default is quite normal. Lots of fonts have a few of the more subtle possible ligatures enabled and many more of the possibly disruptive or unexpected ones off by default and behind discretionary flags. The same goes for stylistic alternative glyphs. Usually the more generic glyph is the default and the fancy-pants ones are behind a discretionary flag. This is normal. Nothing about doing this violates least surprise principles.

Second, source code ligatures do not always easily decompose into their component parts. Your typical ligature for fi is barely distinguishable to the untrained eye and it would hardly cross anybody's mind to type anything but an f and an i to get it. On the other hand nothing about seeing what looks like ≠ in my document will make me thing to type ! then = to get the glyph unless I am familiar with the underling programming language's syntax and the relation of that syntax to the meaning and to the ligature glyph. In this sense enabling such ligatures by default for a general purpose font would violate the principle of least surprise.

Third, for a general purpose font that is not aware of it's context, such ligatures would necessarily b wrong in some contexts. You cannot go wrong with the component glyphs but you can be wrong about when a ligature should be rendered. Maybe a code comment was giving an example from another programming language. Maybe something the character sequence is in the terminal for some reason other than being part of source code. Changing this behavior by default across the board would be frustrating for people that didn't know what was happening or how to fix it because it's not normal behavior. On the other hand folks that knew the language they were coding in and that they wanted to see fancy ligatures should have no problem adding the option flag to their font config.

Lastly not all programming languages will be compatible with the some set of ligatures. Whichever ones you enable by default would invariably end up being wrong for some language. On the other hand if you create ligatures and tag them in the appropriate font features table it's possible to create sets that would include all the appropriate ones on a per programming language basis. This would enable power users familiar with a language to enable ligatures for it in their editor for those files without screwing with their minds for languages whose syntax is new to them.

I look forward to having ligatures as an option, but think trying to make them on by default would be a huge mistake for a general purpose font even if it make perfect sense for a language specific or specialty font whose primary purpose was to provide this feature for a known scenario,

[lozandier]

I meant attempting to have workaround that would disable them in contexts
they normally would be enabled by default.

For editors, they would be turned off by default; it would break the
principle of least astonishment if they were all of a sudden on by default.

On Mon, Sep 7, 2015 at 4:08 AM, Caleb Maclennan notifications@github.com
wrote:

I'm sorry @lozandier https://github.com/lozandier but I don't buy that
line of reasoning. Here's why.

First, OpenType ligatures being off by default is quite normal. Lots of
fonts have a few of the more subtle possible ligatures enabled and many
more of the possibly disruptive or unexpected ones off by default and
behind discretionary flags. The same goes for stylistic alternative glyphs.
Usually the more generic glyph is the default and the fancy-pants ones are
behind a discretionary flag. This is normal. Nothing about doing this
violates least surprise principles.

Second, source code ligatures do not always easily decompose into their
component parts. Your typical ligature for fi is barely distinguishable
to the untrained eye and it would hardly cross anybody's mind to type
anything but an f and an i to get it. On the other hand nothing about
seeing what looks like ≠ in my document will make me thing to type ! then
= to get the glyph unless I am familiar with the underling programming
language's syntax and the relation of that syntax to the meaning and to the
ligature glyph. In this sense enabling such ligatures by default for a
general purpose font would violate the principle of least surprise.

Third, for a general purpose font that is not aware of it's context, such
ligatures would necessarily b wrong in some contexts. You cannot go
wrong with the component glyphs but you can be wrong about when a
ligature should be rendered. Maybe a code comment was giving an example
from another programming language. Maybe something the character sequence
is in the terminal for some reason other than being part of source code.
Changing this behavior by default across the board would be frustrating for
people that didn't know what was happening or how to fix it because it's
not normal behavior. On the other hand folks that knew the language they
were coding in and that they wanted to see fancy ligatures should have no
problem adding the option flag to their font config.

Lastly not all programming languages will be compatible with the some set
of ligatures. Whichever ones you enable by default would invariably end up
being wrong for some language. On the other hand if you create ligatures
and tag them in the appropriate font features table it's possible to create
sets that would include all the appropriate ones on a per programming
language basis. This would enable power users familiar with a language to
enable ligatures for it in their editor for those files without screwing
with their minds for languages whose syntax is new to them.

I look forward to having ligatures as an option, but think trying to make
them on by default would be a huge mistake for a general purpose font even
if it make perfect sense for a language specific or specialty font whose
primary purpose was to provide this feature for a known scenario,

—
Reply to this email directly or view it on GitHub
#35 (comment).

Kevin Lozandier
lozandier@gmail.com lozandier@gmail.com

[i-am-the-slime]

How about having two versions of the font? Hack and Hæck. So people can choose themselves whether they want Ligatures or not.

[lozandier]

That doesn't seem to be efficient al all, if the ligatures tables can be in
the font file as any normal font file & then they're disabled (which they
often are ). Why have to files for something that can be represented in one
file?

Even editors that support ligatures wisely make you opt-in of having them
enabled; it's also a usability issue when they both are installed in
systems that have a wide variety of fonts to the extent they need a font
manager app to selectively disable & enable fonts: It's seems excessive to
account for two variants of the same typeface when the only difference is
ligatures.

On Sun, Sep 13, 2015 at 6:26 AM, Mark Eibes notifications@github.com
wrote:

How about having two versions of the font? Hack and Hæck. So people
can choose themselves whether they want Ligatures or not.

—
Reply to this email directly or view it on GitHub
#35 (comment).

Kevin Lozandier
lozandier@gmail.com lozandier@gmail.com

[chrissimpkins]

Thanks to all for the feedback here. I really like the idea of ligatures with the caveats that I expressed in the thread above. I wanted to provide an update on this issue. I reached out to Tal Lemming (@typesupply) and Ellen Lupton to see if they would be willing to lend their expertise on this and a number of other type design related issues with the project. I think that the concept is great and the question is how we execute this without interfering with the information contained in the source.

For the proponents of ligatures, might I ask that you do a bit of research into the breadth of support that there is for these in widely used source code text editors (including for discretionary ligatures) and the level of difficulty that there may, or may not, be with settings to activate or inactivate the ligatures? I know that Andreas Larsen did a bit of work on this for his Monoid project and we can begin by validating and extending the information that he provides in the README on his Github repo. With this information, we can decide whether we need to clamor for more extensive support by the developers of editors and/or improvements in settings / ease of use of settings to take advantage of these OpenType features. This will allow us to have an informed discussion about ligatures in a working font. We can decide from there whether this is more appropriate as a separate build or within the main release.

While use as a working font in source code editors is the most common application of the typeface at this point, it is not the only one. We need to take this into consideration with developments that (1) may not be attractive to all groups of users and (2) could limit, or eliminate, its use for other purposes because we force users to either use new features like ligatures or introduce an inconvenience that they must design around to avoid use in cases where this is optional (e.g. the CSS web font examples provided above). This does not exclude the possibility that we could be creative in our design and create something that addresses these concerns. I am very open to more feedback and will continue to keep an eye on the discussion here.

[alphapapa]

My two cents, if I may: Hasklig-style ligatures are pretty, but they are by no means intuitive in this context. If a user types two characters on the keyboard, and they suddenly turn into a single character that may or may not actually resemble the two characters put together, it appears as a bug in the font or editor.

If a user is learning a new language, and he's reading the docs, and he sees that inequality is written as !=, but then he looks at some code in his editor and sees a ≠, he is going to be confused. Unless he practically has all the ligatures in the specific font memorized, he is likely to be confused.

What if someone wants to search for a symbol? If one is searching for !=, but seeing ≠, he must remember to type in not what he sees, but the hidden symbols behind what he actually sees.

And in this "Unicode age," where nearly every symbol imaginable has an actual code point and character in some system font, how does one know that he's seeing a ligature and not the actual Unicode character?

What if someone takes a screenshot and shows it to people who know nothing of these magic ligatures? What if someone sits down at another person's computer and sees these ligatures?

They can look very nice, but I'm afraid they are just not a good idea for general use. If the build infrastructure can support a custom build with them, then I'm all for giving people options. And if editors begin to support ligatures, then I'm all for having them in the font as built-in alternatives. But they should definitely not ever be a default feature. To do so would condemn the font to be used by virtually no-one.

They are pretty, though. :)

[chrissimpkins]

from @stefan-kern:

Hasklig: https://github.com/i-tu/Hasklig
Monoid: https://github.com/larsenwork/monoid
FiraCode: https://github.com/tonsky/FiraCode

all of those fonts come with ligatures for the most common programming operators like:

<* <> <+> <$> ** <|> !! || === ==> <<< >>> <> +++ <- -> => >> << >>= =<< .. ... :: -< >- -<< >>- ++ /= ==

since hack aims to be a code typeface it might be a good idea to include these common ligatures aswell.

[chrissimpkins]

Atom editor now supports ligatures:

http://blog.atom.io/2015/10/29/atom-1-1-is-out.html

[lozandier]

Atom already did via author style sheet; I've literally used ligatures in
Atom for years.

On Saturday, October 31, 2015, Chris Simpkins notifications@github.com
wrote:

Atom editor now supports ligatures:

http://blog.atom.io/2015/10/29/atom-1-1-is-out.html

—
Reply to this email directly or view it on GitHub
#35 (comment).

Kevin Lozandier
lozandier@gmail.com lozandier@gmail.com

[chrissimpkins]

@lozandier I see. They seemed to push this as news. I don't use Atom.

[lozandier]

I don't use it often either; I primarily use Vim or Webstorm

On Saturday, October 31, 2015, Chris Simpkins notifications@github.com
wrote:

@lozandier https://github.com/lozandier I see. They seemed to push this
as news. I don't use Atom.

—
Reply to this email directly or view it on GitHub
#35 (comment).

Kevin Lozandier
lozandier@gmail.com lozandier@gmail.com

[ioquatix]

+1

[treybrisbane]

+1

In response to your request for research, Chris, the FiraCode page on GitHub has a fairly extensive list of editors with and without support for ligatures: https://github.com/tonsky/FiraCode#user-content-editor-support

[chrissimpkins]

@Tbrisbane thank you

[chrissimpkins]

We’re tossing around the idea of starting a branch of Hack that includes ligatures and will serve as “working fonts” for development in text editors. This will be developed in parallel with the main Hack branch, be released under a new font name, and address the mounting interest that you’ve expressed here.

For those who are interested in this, will you please chime in again with:

• a list of the idioms / adjacent character combinations that should be supported
• a list of programming languages where these are appropriate/inappropriate in your opinion - this will be necessary to create testing tools to support these sets

As you work through the above, I’d ask you to also begin to think about the design of the ligatures that you suggest. As this materializes, we will plan to create issue reports for the ligatures where the design can be discussed in much more detail. It will be impossible to meet everyone’s demands / needs, but ideas are extremely helpful and will drive the design as the set matures.

Lastly, it would be helpful to have at least one individual with development experience in each language that we define as our supported target languages (see above) who would be willing to commit to testing these during the early, active development phase.

Let’s see what we can pull together. Please continue the discussion here for now.

[i-am-the-slime]

Hi,
So Hæck it is :). I am particularly interested in Scala ligatures and can test drive them. The tool I use is IntelliJ idea which has some beta support for ligatures (https://youtrack.jetbrains.com/issue/IDEA-127539).

The single most important character combination in Scala is => which can even be written as ⇒ but that character looks odd in monospaced fonts. Same goes for -> and <-, which are the next most language specific combinations.
In Scala, many popular libraries have also popularised other types of arrows and other combinations deserving of ligatures: ~>, ==>, ~~>, :=.

There are also some other more general purpose characters which occur in a great many languages: ==, !=, <=, >=, ===, ++, &&, ||. I would personally love for the ! character followed by any letter in abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ to translate to a not character: ¬. I have not seen any other font do that. It would leave exclamation marks used in sentences unaffected, since they are followed by a space. Another cool thing would be for nested parenthesis to render following ones a bit smaller, but that wouldn't work for an arbitrary number of them and at low font sizes.

That's all I can think of for now. It got a bit stream of consciousnessy towards the end. Sorry for that.

[chrissimpkins]

Hæck it is

+1 haha! I love this. Thanks for all of this information. Look forward to this discussion.

[wottpal]

For me would be important implementing the ligatures the "monoid-way" because like in the Atom 1.1 release notes states this is the only one where it is possible for atom to set the cursor between the two ligature-symbols: http://blog.atom.io/2015/10/29/atom-1-1-is-out.html

Note that there is a limitation with FiraCode and Hasklig that does not allow placing the cursor between combined ligature characters like ->. This is a limitation in the Chrome DOM measurement API. monoid does not have this limitation due to the way it implements ligatures."

[chrissimpkins]

@chriskrycho thanks Chris.

Let's wait for a bit more feedback and can decide if this is an appropriate approach.

FWIW, it would be ideal to simply work on Haack but I have not heard back about time/interest there. How recently has that project been updated, is it being maintained current with Hack upstream, and are PR being accepted / merged from contributors?

I don't use ligatures so this won't be for my own use, but given the interest out there (and opportunity to create some interesting new glyph shapes which seems like a fun challenge) I am willing to contribute time to this.

[chriskrycho]

As far as I can tell, Haack had one release and then the author went completely silent. Alas!

[chrissimpkins]

OK we will revive this. Thanks Chris.

[vikky49]

I patched Hack font with ligatures using this https://github.com/rojiani/Ligaturizer and it really looks good. Its a good alternative till Hack has its own ligatures

[ignatov]

@vikky49 Cool, could you please provide binaries?

[chrissimpkins]

Looks like perhaps they do for regular set only?

https://github.com/rojiani/Ligaturizer/blob/master/output-fonts/Hack.ttf

[chrissimpkins]

@vikky49 worth pushing a repo with those ligature patches and keeping this current with the Hack upstream?

[vikky49]

sure .I can push my binaries ..but the problem is its based off of Fira Code and FiraCode does not have italics .So at the moment only the regular version has ligatures but so far i did not find it as a problem as 90% of my mainstream code that uses is regular font ..Italics are widely used only for comments and stuff for the work i do..

The original version of the script has very limited ligatures .So I modified the script to have many more that are useful

@chrissimpkins to which place do i upload the binary

[chrissimpkins]

Ideally to your own new repository where you can host these changes for others who would like to use the binaries. Mind also posting some images there with what has been implemented so far as source code targeted ligatures?

[vikky49]

@ignatov and @chrissimpkins Here you go ..My version of modified ligatures over the
https://github.com/rojiani/Ligaturizer/blob/master/output-fonts/Hack.ttf

My Version of ligatures binary can be found here

https://www.dropbox.com/s/682w2cb8p0d018h/Hack.ttf?dl=0

[vikky49]

@chrissimpkins sure .Will host all these changes into my repository some time this week and post the link

[chrissimpkins]

@vikky49 sounds great. Let us know when it is available. We are maintaining a thread of derivatives and will find someplace to link these for users.

[vikky49]

@chrissimpkins @ignatov Now the new Ligaturizer has been updated to support all the variants like Bold , Italic and BoldItalic.. I have patched the Hack font again with the latest fonts and removed some ligatures which look very specific for Fira Code like (&&) . I have uploaded the binaries in my repo ..It can be found here

https://github.com/vikky49/patchedFonts-Ligatures

[chrissimpkins]

@vikky49 thanks! Willing to open the scripting that you used to accomplish this so that others can examine & replicate it?

[vikky49]

@chrissimpkins If u mean by the modifications of ligatures that i did ,, sure i can open put it up in a repo

[chrissimpkins]

@vikky49 that would be helpful too (along with images on your README so that users can see what they are getting with your ligature changes), but I was actually referring to a script that includes how you built the fonts with the Ligaturizer project. Possible to add a shell script / Makefile or some other approach that allows users to understand and compile the patched fonts in the way that you did?

[chrissimpkins]

This font renaming script is available for anyone who would like to install Hack derivatives side-by-side with upstream Hack if there is any use in having both installed (e.g., you are using it outside of work in source text where ligatures do not apply)

https://github.com/chrissimpkins/fontname.py

[pyrho]

For those interested I've "patched" @vikky49's ligatured version with nerdfont (powerline glyphs, dev icons etc.).
You can find it here !

[chrissimpkins]

@pyrho ty!

[bensleveritt]

I'm a little confused about the situation now (I got here after stumbling into hæck today). Is there an 'official' Hack Code? Or is @vikky49's patched font the best course of action?

I've tried to follow along, but I can't work out if this issue is still open for 'intent-to-change' or informational purposes only.

[bensleveritt]

Just to be clear. If an 'official' one is on the cards, I'd be willing to spend some time making it happen. I'm really pleased with Hæck, and I think it's pretty far behind Hack now. I'd love to see what's changed.

[Thesola10]

@bensleveritt

As I understand it, @vikky49 has successfully patched Hack with ligatures extracted from Fira Code, but they have not yet released a script describing their patching process, meaning that the patching process cannot yet be merged into the Hack project, and a ligatured font can't be reliably produced and maintained.

[chrissimpkins]

This is correct. There is no upstream Hack ligature set. @vikky49 patches are available. There are no immediate plans to release source code ligatures in this repository however I would be happy to pitch in on an effort to help make this happen in a derivative if anyone wants to take on the maintainer + design responsibilities for that project. There should be a reasonably straightforward way to merge any design changes here with that downstream repository. There is a lengthy story about my concerns with ligatures detailed very early in this thread. Let me know how I can help support this. It has been in high demand for a long time. I just don't have the cycles to tackle it myself.

[soetz]

@chrissimpkins

I'd LOVE to (try to) do it ! Problem being I've never designed/made/coded fonts before.
Do you have any resources so that I could learn how to use all the tools needed for this ?

[joshmcarthur]

Along with @vikky49's patches (which are now a little out of date since they were initially generated and then not maintained), I have found that the Ligaturizer project mentioned above (https://github.com/ToxicFrog/Ligaturizer) builds and releases a version of Hack with ligatures added from Fira Code.

Ligaturizer builds the Liga Hack font from @chrissimpkins's own codeface project, and publishes to their releases page. While the releases don't appear to be continuously build against codeface@master, there are regular updates, so this is probably a good source if you're not wanting to build the font yourself.

In terms of rolling this into this project, I can see three easy-ish options:

1. If Ligaturizer was added as a tool available to the build process of this project, it could prepare a variant of the Hack font with ligatures added as part of the release (Ligaturizer just needs to be pointed at TTF files and can automatically prefix the font name - e.g. Liga Hack, Hack Code, etc, or rename it entirely - e.g. LigaHack)
2. This project could pull in the pre-built font files from the Ligaturizer releases page. This is probably problematic since the font is probably quite out of date by the time it makes its way through the Hack -> Codeface -> Ligaturizer repos and build processes - but it's an option
3. The README and/or other documentation could be updated to direct potential users to the release of Ligaturizer that includes the variant of Hack.

[vikky49]

Sorry..I will soon update all of them again..I have been a bit lazy..I just saw a PR which updates the ligaturizer with the latest Firacode changes.. All the updated fonts should be out in a week

[joshmcarthur]

@vikky49 no pressure! You've made a fantastic contribution for this issue as it is. I just wanted to point out that there's an alternative available if anyone is wanting to quickly grab the release from Ligaturizer

[gaplo917]

Along with @vikky49's patches (which are now a little out of date since they were initially generated and then not maintained), I have found that the Ligaturizer project mentioned above (https://github.com/ToxicFrog/Ligaturizer) builds and releases a version of Hack with ligatures added from Fira Code.

Ligaturizer builds the Liga Hack font from @chrissimpkins's own codeface project, and publishes to their releases page. While the releases don't appear to be continuously build against codeface@master, there are regular updates, so this is probably a good source if you're not wanting to build the font yourself.

In terms of rolling this into this project, I can see three easy-ish options:

1. If Ligaturizer was added as a tool available to the build process of this project, it could prepare a variant of the Hack font with ligatures added as part of the release (Ligaturizer just needs to be pointed at TTF files and can automatically prefix the font name - e.g. Liga Hack, Hack Code, etc, or rename it entirely - e.g. LigaHack)
2. This project could pull in the pre-built font files from the Ligaturizer releases page. This is probably problematic since the font is probably quite out of date by the time it makes its way through the Hack -> Codeface -> Ligaturizer repos and build processes - but it's an option
3. The README and/or other documentation could be updated to direct potential users to the release of Ligaturizer that includes the variant of Hack.

For those who are looking for Liga Hack v3.003, I can confirm that current Ligaturize is not able to build Hack v3.003.

I submitted a pull request to fix that and also created a standalone repository "Ligatured-Hack" which implemented with a fully automated build process to build latest "Liga Hack".

I use Travis CI run a daily cron job to check both Hack / Fira code release version. If CI detected a new font release, it will build a new "Liga Hack" release automatically.

Latest build can be found in https://github.com/gaplo917/Ligatured-Hack/releases

This implementation should be self-maintained that automatically combine latest Hack & Fira ligatures together without any human maintenance 😄.

P.S. A warm reminder, the above implementation use Fira code ligature but not Hasklig.

[astrolemonade]

@vikky49 what are the names of the IDE and theme from the screenshot above ?

[rofrol]

@gaplo917 Ligaturizer works with latest Hack.