←back to thread

Can your terminal do emojis? How big?

(dgl.cx)
178 points dgl | 1 comments | 24 Jun 25 02:13 UTC | HN request time: 0s | source
Show context
hnlmorg ◴[24 Jun 25 07:35 UTC] No.44363733[source]▶
> Alternatively, you might not want to use literal 1970s technology and be interested that Kitty recently introduced a more modern way to get different sized text in a terminal.

Kittys “modern” way of doing it is still 1979s tech. Kitty just decided it would discard the standard escape sequences because of “reasons”.

Honestly, much as some of Kittys custom sequences have improved things, this particular sequence doesn’t.

replies(2): >>44363782 #>>44363817 #
the_gipsy ◴[24 Jun 25 07:53 UTC] No.44363817[source]▶
It does improve because IIRC support for the old sequence cannot be reliably detected.

https://github.com/benjajaja/mdfried utilizes the new protocol and an image render fallback.

replies(1): >>44370043 #
hnlmorg ◴[24 Jun 25 19:30 UTC] No.44370043[source]▶
I don't buy that argument. The old sequence is part of vt100 and supported by xterm. The new sequence is only supported by Kitty. If the Kitty dev wanted to make feature detection easier then they wouldn't have duplicated a feature that has been a staple for terminals for literally decades.

Also the tool you shared has nothing to do with this. It’s just a 3rd party utility.

replies(1): >>44376200 #
1. the_gipsy ◴[25 Jun 25 11:50 UTC] No.44376200{3}[source]▶
Feature detection is not the only reason the new protocol exists; it offers a variety of options to create scaled text (not only x2) and alignment, and it can be detected reliably, unlike the older sequence which is also not widely supported anyway.

This was my experience when writing the tool, which had started out only with the image rendering, but then could use the new kitty protocol. The old sequence is moot for this use case, because it's impossible to query if supported and only can scale to x2.