Repository navigation
Support for ligatures #50
Description
I would love to see the support for ligatures (an example of their use might be found in https://github.com/tonsky/FiraCode). Please note that i have almost no idea how do they work under the hood, and so i don't know how hard is it to implement support for them, I'm just throwing an idea here.
Anyhow i think this is a great project, congratulation! :)
Activity
jwilm commentedon Jan 4, 2017
I would really like to support this! It falls into the categories of things Alacritty cares about which include quality font rendering and performance.
Thanks :)
aperezdc commentedon Jan 23, 2017
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 😉michelboaventura commentedon Feb 3, 2017
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).
3goliad commentedon Feb 4, 2017
Qterminal and Konsole share the same implementation, AFAIK, and correctly render ligatures in input lines, excepting when under the cursor.
For further reference:
f-koehler commentedon Feb 4, 2017
@3goliad I use konsole and always considered this behaviour to be intended. It would be nice to have a similar implementation in alacritty.
mrkgnao commentedon Mar 4, 2017
I'd love this too!
zovt commentedon Mar 17, 2017
Anyone currently working on this?
munyari commentedon Apr 11, 2017
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?
pvaibhav commentedon May 2, 2017
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.
tbodt commentedon Jun 16, 2017
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.
beefsack commentedon Jun 25, 2017
Other complexities might include how to render ligatures when the characters are broken over multiple lines.
tbodt commentedon Jun 25, 2017
It doesn't really make sense to do that IMO.
OJFord commentedon Jun 30, 2017
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.120 remaining items
ItsNilDev commentedon Nov 16, 2020
remove alacritty-related files
ExpandingMan commentedon Mar 2, 2021
Just wanted to poke my head in and ask opinions about whether this will ever be implemented or is dead in the water.
kinooyume commentedon Mar 10, 2021
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 👼
kinooyume commentedon Mar 11, 2021
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
Felixoid commentedon Mar 11, 2021
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 =)
chrisduerr commentedon Mar 11, 2021
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.
Felixoid commentedon Mar 11, 2021
Yep, l exactly mean attitude like this.
sQVe commentedon Mar 11, 2021
@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.OJFord commentedon Mar 11, 2021
@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.)
FlyingWaffleDev commentedon Mar 11, 2021
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?
runiq commentedon Mar 11, 2021
Please take the time to read through this very thread. There are a number of issues described with the various forks implementing ligatures.
FlyingWaffleDev commentedon Mar 11, 2021
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?
chrisduerr commentedon Mar 11, 2021
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.