Question: why character grid?

[maximbaz]

This is not a bug or a feature request, but a question that I'm genuinely interested to ask you.

This project's goal is to make a terminal that is modern and sexy, not be restricted by limitations of the past age. GPU rendering, graphics, unicode, true color, ligatures, window layouts and much more, everything is very pleasant.

So why are we still bound by the character grid? Isn't this just another artifact of the age of hardware terminals?

I managed to find this comment saying that performance would have been terrible otherwise, but is that not an exaggerated statement? I'm sure it is possible to write GUI apps that are maybe slower, but still not terrible at performance.

But I wonder if there is more to it. Some feature requests were closed as "this cannot be done in grid-based terminals", I want to understand if having character grid in the first place was a conscious decision, and if so what were the reasons behind it.

[kovidgoyal]

Because this is a terminal emulator. And terminals are character based devices. Limitations are often a spur for creativity and the limitation of needing to interact via character based devices has resulted in an entire ecosystem of terminal programs whose interface and design characteristics are both limited to and also enhanced by the fundamental nature of the TTY device. This is not a set of constraints I want to lift. So my mission is to make the best possible terminal emulator.

And just incidentally, when I say performance, I dont mean raw rendering performance. Even 3D games have more than adequate raw rendering performance on modern hardware. Most modern termial emulators have more than adequate performance.

By performance, I mean CPU/energy usage to perform a task.See https://sw.kovidgoyal.net/kitty/performance.html

[maximbaz]

I see, thanks for the answer. So do I understand correctly that if there was an app that looked like kitty, but wasn't based on a grid and allowed variable-width fonts, you wouldn't call that app a "terminal emulator"? Also, is it just a game of definitions, or there would be some conceptual challenges, e.g. vim wouldn't be able to run if there was no fixed number of columns in a row? Sorry if that's a dumb question, but I don't know if vim actually depends on a fact that there is the same number of columns in all rows.

Thanks for explaining the meaning of performance in this context, quite interesting.

[kovidgoyal]

Yes, the problem is not just vim. Fundamentally all interactions in a terminal happen via a cursor. The cursor has to move a cell at a time. In a non-grid terminal (konsole is one example) you get lots of cursor movement related bugs, because there is no concept of a cell, so the emulator has to have some kind of virtual cell abstraction, that does not mach the actual rendered text very well. If you search konsole's bugzilla you will see examples of that. And of course performance (in the CPU usage sense) is horrible as you can see by looking at the table on the kitty performance page.

Basically, kitty's design allows it to render every character it display only once. In contrast for non-grid based rendering you have to re-render every changed line every time. This has the advantage that you can support complex scripts/infinite length ligatures, etc. The disadvantage is performance (in CPU usage sense) and cursor positioning bugs.

[Althorion]

AFAIK (I don’t have the actual font) Pragmata Pro is monospaced, just it implements ligatures differently than Fira Code—every simple glyph is the same size and ligatures are a multiple of that.

The same, I believe, goes for Iosevka, which doesn’t work in Kitty either, but never caused me any problems in all other fix-width only applications.

[kovidgoyal]

According to #557 pragmata pro's ligatures work fine in kitty. As for Iosevka it insanely supports infinite length ligatures, which I absolutely refuse to do for performance reasons, see #297

[ahmedelgabri]

According to #557 pragmata pro's ligatures work fine in kitty. As for Iosevka it insanely supports infinite length ligatures, which I absolutely refuse to do for performance reasons, see #297

Font choices are a personal preference & it depends on many things, what the person likes, their screen, eye sight, OS rendering, etc... & also not everyone can afford PragmataPro. Plus people expect fonts to just work, especially if they work in all other apps on their system just fine.

Asking people to change what they like shouldn't be part of installing an app, it's like releasing an app with only one theme & asking everyone else to just get used to this theme, won't work. Because these things are very subjective & depends on taste & other factors.

Kitty is by far the best terminal emulator right now & I really appreciate the work done in this project. This is the only thing that it's missing to be complete IMO. I really hope that this can be changed at some point.

This is just my 2 cents.

[andreypopp]

@ahmedelgabri maybe Iosevka should be fixed instead?

[Althorion]

I’ve asked for a compatible version to be pre-build and you can build one yourself from the source, I think—my nodejs installation hates me, so I can’t just go and check by myself, will try to find some time to fix it and rebuild.

[ahmedelgabri]

@andreypopp Both sides have valid reasons in the argument, I just hope we can find a middle ground. See Iosevka's author comments #297 (comment) & #297 (comment)

[kovidgoyal]

I'm afraid there is no middle ground, at least that I can see. As long as Iosevka insists on having infinite length ligatures, there is simply no way to support it in kitty. It's a pity, but that's what it is.

And I never suggested using Pragmata Pro, I simply mentioned that unlike Iosevka, Pragmata Pro's ligatures do work in kitty. As do the ligatures from many other fonts. Indeed, I think Iosevka is the only one that does not. And even with Iosevka if you really, really want to use it, use the variant without ligatures.

[fuloating]

I am not sure if this is a related question, or whether I should have created a new issue or contacted through other means, but I want to know if there is a solution in kitty for this scenario:

I created a test font in fontforge from Monoid font, renamed its family to Monoid2. What I did to it is I created a ligature substitution in the lookup to substitute "ab" to "¡". Now when I use this font in the qutebrowser, the string "abc" looks like "¡c" and same is with another terminal emulator qterminal, but with kitty it looks like "¡ c". It reserves an extra block, and what I understood from the technical text in some of the discussions here it is a feature.

My question is if there is a way to make it appear like "¡c" in anyway in kitty? (whether it is another approach in fontforge or configuring kitty settings or such)

[kovidgoyal]

No, there isn't. If you want to combine to characters into another, you should use a unicode combining character for that, then kitty will convert char+combining char into a single cell glyph.

[fuloating]

Okay thank you. I tried looking at that quickly and seems complex. The fontforge is a complex program so I need to go to their forum to figure out if it's something I could work on.