-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for ligatures #50
Comments
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 :) |
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 |
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 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. |
I would say it does: e.g. if you know you have a |
@OJFord 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:
Maybe not. How to distinguish This font supports unlimited-length ligation: https://be5invis.github.io/Iosevka/ |
@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 $ 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")- |
@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? |
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 |
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? |
Yes, for sure. Need a lot more time for this, at least not during the leasure time at work...
|
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. |
Hello, how can I be of assistance? |
how to enable font ligatures on the config? |
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! |
This comment has been minimized.
This comment has been minimized.
I won't be using Alacritty any time soon, because * it does not support ligatures yet, see alacritty/alacritty#50 * it does not seem to support any dynamic configuration so I can't use light or dark theme based on the OS theme
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. |
Also, I didn't test but this repo seems to implement it: https://github.com/zenixls2/alacritty (thank's xenixls2 ) |
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 |
@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.) |
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? |
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'. So "performance über alles" then? |
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. |
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! :)
The text was updated successfully, but these errors were encountered: