Hacker News Reader

Comment by dbz | Hacker News Reader

Is there somewhere we can view the feature roadmap for this? Will iTerm2 support ligatures at some point in the future? I'm also interested in future performance enhancements, and a comparison to terminal.

View on HN

There is no official feature roadmap, but here's the current plan:

3.2.x will be focused on rendering improvements. The full change log is here: https://iterm2.com/appcasts/testing_changes3.txt

3.3, which is currently under development, is adding a Python scripting API (https://iterm2.com/python-api/) and fixing tab and window titles to make sense, plus adding a status bar.

Feature requests that are candidates for 3.4 are here: https://gitlab.com/gnachman/iterm2/milestones/8

If you have something in mind file an issue. Y'all are my PMs.

There is already support for ligatures (prefs>profiles>text>enable ligatures). The Metal renderer does not support them because that's an extra level of complexity I can't handle in the first release. It would require constructing CTLineRefs which is already the slowest part of drawing. Subpixel antialiasing also makes this really difficult, but since that's going away in Mojave I'll revisit it.

Future performance enhancements that I have in mind are: - Faster tokenization (including revisiting SIMD) - Mojave-specific optimizations (removing subpixel AA and its knock-on consequences) - Move per-frame setup work into a compute shader. This is tricky because some people have CPUs that are relatively faster than their GPUs (thanks Intel!) - Reuse the preceding frame's rendered texture when updating less than a full frame - Move work off the main thread where possible

Thanks for the infos and of course all your hard word, iTerm2 is an awesome piece of software.

Looking forward to Mojave dropping support for subpixel-antialiasing and maybe iTerm supporting Ligatures with the new drawing engine someday.

Yeah, I’m wondering about this too. I like transparent windows and font ligatures so as much excitement as I have about this, I won’t be able to use it unless these limitations can be eliminated. I’ll keep using iTerm regardless, but it would be nice to see the benefits become available for my setup as I do notice the performance issues.

I'd just disable them. Speed and lighterweight (on CPU) rendering are more important that ligatures and transparency, which are both gimmicky features.

I disagree that ligatures are gimmicky in a general sense, but they definitely don't seem necessary for a terminal window. And doubly so if they impact performance.

Ligatures are great in a terminal with the right font. For example Fira Code does some nice things with ligatures for not-equal, 0x, rockets, etc.

This is a Mac program. One of the reasons why the Mac has historically been far ahead of other platforms is because its display could leverage centuries of advances in typography, and not be confined to the a 1970s character cell display designed by illiterates. Ligatures are extremely important for the platform and for the audience.

We're talking about ligatures in console based programming editors.

Not about setting ligatures for print.

So the whole argument is kind of moot. Having ligatures in console vi is not what made the Mac "historically be far ahead of other platform". In fact for the first 15 years of its life the Mac didn't even have a console.

Even in the desktop GUI program world, where ligatures in programming IDEs and editors are a possibility, they're still an extremely fringe endeavor.

This is true, but terminals tend to be used with monospace fonts that aren't very typographically complex.

That said there may? be languages other than English where ligatures are more than decorative, and would be more useful to have in a terminal.

I'm saying, maybe the terminals of today need to be more typographically aware, now that the computers of today can more than support it.

On the list that terminals need to do, being more typographically aware is on the very bottom on my list of priorities.

They could start by not mimicking 50+ year old hardware terminals down to arcane (and performance killing) details, supporting better and more powerful autocomplete and similar interactions, inline images, full colors, and so on...

It’s important to some people but probably not a majority. Ligatures are a best effort kind of thing. Where trade offs must be made, such as drawing performance, I choose to let the user make that choice.

And it sounds like they wouldn't, and that their priorities are different than yours.

I believe in an external world, where not everything is a matter of personal "priority", but certain things are objectively more significant than others.

And I might be wrong, but in that world, ligatures and transparent terminals are not really as important as rendering speed, latency, and/or less CPU load for a terminal emulator.

In fact, even where available, ligatures are a fringe option, adopted by very few people.

(I'm always talking about programming editors. Though even in print, their main domain, they're hardly mainstream these days).

I'm never bothered by iTerm2 being too slow or using too much CPU. Using transparency for my tmux profile makes it easier to tell whether the tab I've switched to is a local or remote session. Seeing coding ligatures makes me happy.

Why is the thing I don't notice objectively more important than my convenience and happiness?

It supports them now. I use fira code.

Per the article, the Metal 2 renderer doesn't support ligatures, transparency, and a few other nice-to-haves.

The original asker asked, "Will iTerm2 support ligatures at some point in the future?", so it was indeed a helpful answer to know that it does support ligatures.

I mean, within the context of this thread, it's pretty obvious the original question is asking whether ligatures would be supported in the Metal renderer, since it's explicitly listed as something not supported in the article, and since the asker is asking for the "feature roadmap for this".

Reply on news.ycombinator.com