I would really like to support this! It falls into the categories of things Alacritty cares about which include quality font rendering and performance.

Anyhow i think this is a great project, congratulation! :)

Thanks :)

Support for ligatures would be indeed super nice. One terminal emulator that handles them quite well in my experience is Pangoterm, though I have not looked at the code to see whether it does something explicitly or it just delegates the task to Pango — anyway, leaving the link here as reference, in case it's useful to gather inspiration from its code.

For reference, the following screenshot shows an interesting behaviour of Pangoterm: ligatures are not handled in the lines/cells where used input is done, but only in the ones where output is shows. I suppose that it's easier to handle because it's not needed to backtrack and redraw the line where the cursor is to have ligatures applied during input:

(Pangoterm on top, Alacritty on bottom. Of course, if the same line used for input receives output from a program e.g. Vim, then ligatures “appear”.)

Edit: BTW, Alacritty is awesome! It reminds me of GLterm, which was my go-to terminal emulator back in the early 2000s (mentioned here, the official site at http://www.pollet.net/GLterm/ seems dead). Alacritty is the first terminal which feels as fast and snappy as GLterm back in the day 😉

I use qterminal, which has full support for ligatures and seems to have a more recent implementation of a terminal. I think it's a nice example of how to handle ligature (and unicode in general).

Qterminal and Konsole share the same implementation, AFAIK, and correctly render ligatures in input lines, excepting when under the cursor.
For further reference:

@3goliad I use konsole and always considered this behaviour to be intended. It would be nice to have a similar implementation in alacritty.

I'd love this too!

Anyone currently working on this?

What would need to change in order to support ligatures? And I assume ligature support would extend not just to programming fonts in ASCII, but any unicode script, correct?

I had a cursory look and it seems alacritty renders one glyph at a time and then caches it. For ligatures, an entire line needs to be rendered at a time, and this should be delegated to the platform-native text renderer. The alternative would be checking character combinations and rendering their ligatures as a new glyph, but then we're doing work that's already done by the text layout engine. I didn't continue researching further because I don't know Rust or OpenGL well enough to implement this.

Not an entire line, an entire part of a line with the same formatting (since it doesn't make much sense for ligatures to cross formatting boundaries.

Probably the best way would be to read the ligature info from the font and use that to search for ligature sequences in a formatting group, then render those sequences and cache that.

Other complexities might include how to render ligatures when the characters are broken over multiple lines.

It doesn't really make sense to do that IMO.

Other complexities might include how to render ligatures when the characters are broken over multiple lines.

It doesn't really make sense to do that IMO.

I would say it does: e.g. if you know you have a -> ligature and you see -\n>, it's going to look like you've entered - > accidentally.

@OJFord a ligature is supposed to be one glyph.. so how could it be broken into 2 lines?

a ligature is supposed to be one glyph.. so how could it be broken into 2 lines?

Just break it, or see how double-width characters are dealt with.

@pvaibhav Adding to my previous comment:

a ligature is supposed to be one glyph..

Maybe not. How to distinguish ff (ff) from -> (→)? In practice there should not be a ligature for "ff" in a monospace font? ;-)

This font supports unlimited-length ligation: https://be5invis.github.io/Iosevka/
Rendering in the browser:

@pvaibhav I meant that if the constituent characters are line-broken, the ligature should still be rendered (on either one of the lines) - since if you know your font ligates ->, and you see:

$ long long long long line that ends after -
>

you could easily mistake that for having an erroneous space (or linebreak) - at least, I know I would be constantly hitting backspace-backspace-("oh")---> to check.

@OJFord I don't think the ligature should be rendered on that case, wouldn't that just sometimes make your terminal to have less/more width? The behaviour of qterminal on that seems just fine (terminal on the left)

Any update on this effort?

Collecting information on this. Here's the commit which introduced support in iTerm. Should be worth looking at for the macOS side. This commit is also relevant

I'm afraid iTerm2's code won't do you much good as all the layout happens in macOS's dreadfully slow and AFAICT single-threaded layout engine. I am of the belief that using an open source layout engine is your best bet—you can get at the opentype tables from macOS, but making this work goes way beyond parsing LIGA tables as there's a great deal of complexity around glyph reordering. A few other tables whose names escape me are involved. Look at FiraCode to see the madness.

Perhaps it would be useful to look at the approach https://github.com/daa84/neovim-gtk takes to ligatures (as it's also written in Rust)? I haven't isolated the commit where this support was added, however - I think it might be this: daa84/neovim-gtk@dc8d6d5

That won't help, it's doing pretty much the same thing as iTerm 2.

Kitty has partial support for ligatures (char supstitution like in the case of Fira Code) but fails for Iosevka. Related discussion kovidgoyal/kitty#297

There's another issue in my ligature branch that CJK characters under selection will only have first half part shown. Have no time to test in @Philipp-M 's branch, but should have the same issue. Still finding where the bug is. fixed

For the arrow issue you mentioned, I'm not sure about what the real behaviour is on your side. Can you upload some screenshots/gifs to show?

PS. Commits from @thunderseethe are all compressed to a single commit for easier rebase. Wish this won't offend the author.

@zenixls2 Would this help with not forking rust-freetype?

Also: zenixls2@b92f094#r39874718

/cc @wezm Am I doing appropriate math, there?

@zenixls2 Would this help with not forking rust-freetype?

Yes, for sure.

Also: zenixls2@b92f094#r39874718

Need a lot more time for this, at least not during the leasure time at work...

/cc @wezm Am I doing appropriate math, there?

Please, could you move the discussion related to your fork to a tracker on your fork instead of pinging a lot of folks on that issue each time. thx.

/cc @wezm Am I doing appropriate math, there?

Hello, how can I be of assistance?

how to enable font ligatures on the config?
Ive added fire code on font but nothing happens
ive installed the archlinux repo with ligatures

Alacritty does not have support for ligatures.

Hey @chrisduerr , would you be able to tell me the components that would be involved in this effort? I don't really understand how fonts are supposed to be rendered by alacrity.

All the information necessary to implement this should already be present in this thread, given that there was a PR before that attempted to implement it.

If that doesn't get you started, chances are that working on this is mostly going to be a waste of time. Implementing it isn't the problem, doing it properly is. So people that are struggling with getting started are probably not going to have an easy time implementing this.

what a narrow mindset

Come on guys, show a little respect! @chrisduerr is doing this out of his free time. The bigger a project gets, the more work there is, the more thankless it all gets. For all the effort you've poured into this project Christian, my thanks!

Just wanted to poke my head in and ask opinions about whether this will ever be implemented or is dead in the water.

It seems to be a huge work to do it well. Unless someone dedicated itself to this, it seems hard to implement that while maintaining the project.
Let's hope an angel fall from the sky and save us all 👼

Also, I didn't test but this repo seems to implement it: https://github.com/zenixls2/alacritty (thank's xenixls2 )
If you're on arch linux or derivated, you also have an AUR for that: https://aur.archlinux.org/packages/alacritty-ligatures/
So hope is permitted I guess

As far as I get, maintainers wait for the perfect solution and don't want to use a working one.

As a user of https://aur.archlinux.org/packages/alacritty-ligatures/ and not a developer I don't get why. And not blame them. But still don't get it =)

If you want ligatures so badly that you're willing to run a low quality fork, I'd recommend switching to a terminal emulator that natively supports ligatures.

Yep, l exactly mean attitude like this.

@Felixoid What attitude are you getting at? The maintainer is simply giving a recommendation. There's a very large amount of users that doesn't need or want the ligatures feature in alacritty. What you're, and others, are suggesting is just to wing it - which in the end might have implications on performance, scalability and not the mention the code base.

@chrisduerr May I suggest locking this thread? I can't imagine anything useful will be said until a potential "PR here please help test". If that ever happens (and it's a decent merge candidate) it'll have your or another maintainer's attention and you'll unlock or comment to that effect yourself as you see fit.

Otherwise it's just going to be an endless stream of notifications for 'any update?' and 'no'.

(Before it's suggested at me: I don't want to unsubscribe, since I would like to hear of any progress, but SNR is not good on such a popular but complex issue, so yes, I might. But subcribed to a thread that's locked for now or has maintainer updates only would be better IMO.)

If you want ligatures so badly that you're willing to run a low quality fork, I'd recommend switching to a terminal emulator that natively supports ligatures.

Would you care to comment on WHY you refer to it as a 'low quality' fork? Are there some standards it's breaking, some performance metric not hit, an option to disable that isn't implemented, or some other reason? Earlier you commented that any ligature implementation must be done 'properly'. Could you please explain what you mean by that, so people attempting to do so actually have a mark to aim for?

If you want ligatures so badly that you're willing to run a low quality fork, I'd recommend switching to a terminal emulator that natively supports ligatures.

Would you care to comment on WHY you refer to it as a 'low quality' fork?

Please take the time to read through this very thread. There are a number of issues described with the various forks implementing ligatures.

Please take the time to read through this very thread. There are a number of issues described with the various forks implementing ligatures.

I've done that before, just did so again now. As far as I can tell the first bit of the thread consists of "How should we implement? Here are examples from Kitty, iTerm, etc", then the conclusion that the required changes for ligatures (which incidentally also allow CJK and bidirectional text) are too expensive in terms of 'performance'.
Then there's the middle chunk which focuses on "well, if you won't do it, and I can't code, lets fund the effort so someone else can" which doesn't seem to get anywhere.
Finally, a pull request that is again pushed aside for 'performance issues'.
Then a fork that introduces a bunch of bugs, but works.
And then a fork of that fork (this is the one in question, zenixls2's) which resolves those bugs and as far as I can tell from their testing (https://github.com/zenixls2/alacritty/blob/ligature/performance.md) doesn't introduce performance issues [admittedly I'm not 100% sure what those performance metrics actually mean, but the numbers don't look all that different].

So "performance über alles" then?

Are there some standards it's breaking, some performance metric not hit, an option to disable that isn't implemented, or some other reason?

It neither measures up to Alacritty's performance, nor code quality standards. It's an initial proof of concept and nothing more. The benchmarks done by the various forks trying to indicate the performance is fine largely just show a lack of understanding when it comes to benchmarking Alacritty or terminals in general.

As @runiq has said, every problem has been reiterated numerous times and I agree with @OJFord that there hasn't been anything productive going on in this thread for a long, long time.

If someone is interested in picking this up and willing to actually put in the time to finish it, please send a PR. I'm also always available on Alacritty's IRC for a more synchronous communication.