Hacker News Reader

Comment by aidenn0 | Hacker News Reader

I agree that using the 8-bit CSI to eliminate the escape ambiguity would be great. The rest I'm a bit "meh" on. In particular I use C-S as the modifier for my terminal shortcuts, so if the terminal could detect it I'd be looking for yet another set of bindings that no terminal programs will ever use.

View on HN

The only decent solution in my view would be a new, separate kind of terminal spec, maybe even completely focused at terminal emulators. It could make sense to handle input better(maybe even with keyup/keydown events) and maybe display images in a non-hacky way(it can already be done via w3m...kind of).

Changing the existing standards just won't work as it would break a ton of programs, although if I'm being honest - while I like the idea of such a terminal rework - I don't know if it can be done nowadays without it opening the flood gates by developers who just can't restrain themselves from adding so many features it might as well be a new browser engine.

And either way I don't think it's worth the effort as those input limitations only affect a few specific situations. I use hundreds of custom keybindings in Vim and so far the only obstacle I encountered was the `Tab` & `Ctrl-i` overlap. If I need to hold down more than one modifier I did something wrong anyway.

https://sw.kovidgoyal.net/kitty/keyboard-protocol.html

https://sw.kovidgoyal.net/kitty/graphics-protocol.html

Looks great, the only gripe I have with Kitty is how slow it is, especially on startup. I guess mostly because the combination of Python and tons of features has a negative effect in this area. In fact that was the only reason I switched away from it despite its great font ligature support; I use terminals a lot and so the constant delay when opening a new window was a bit much.

However I like those modernised protocols and it would be neat to have widespread support for it.

This! I would love a "purified" version of kitty which is just an xterm with font ligatures. And no silly features like underlining of links, etc. Also, an option to display bold text by using brighter colors (as God intended).

kitty startup time was slow because of a bug in GLFW, fixed a while ago. And you can have its startup time be 0 with --single-instance.

Using the latest kitty release 0.19.3 vs. st, both already loaded:

  ~ >=> time st ls

 real   0m0.048s
 user   0m0.041s
 sys    0m0.008s
  ~ >=> time kitty ls

 real   0m0.239s
 user   0m0.173s
 sys    0m0.059s

If kitty isn't nicely cached it takes over 500ms on my machine. Using your suggested flag it still takes twice as long.

You need to run kitty -1 to start kitty and leave it running. Then all future kitty -1 invocations will open new windows instantaneously.

I use kitty.

"time kitty -1 true" takes about 180ms on my machine. That's more than fast enough for me, but certainly slower than many other terminals.

It's still an order of magnitude slower during startup than other terminals such as xterm, rxvt or even mlterm. On my intel laptop I can often see the gl context flashing before becoming the final background color, which is annoying. Requires also way more ram.

kitty is a great terminal, but it's one example of fast not being also lightweight.

I cant reply to your other post, so: you need to run the other kitty instance also with -1. If you do that, you will get the same numbers I got.

I know, I'm actually using kitty regularly.

time kitty -1 false real 0.098 user 0.080 sys 0.017 maxmem 23 MB faults 0

time xterm false real 0.052 user 0.035 sys 0.000 maxmem 9 MB faults 1

Doesnt look like an order of magnitude to me.

xterm false 0.06s user 0.01s system 81% cpu 8Mb mem 0.090 total

mlterm -e false 0.08s user 0.02s system 84% cpu 13Mb mem 0.125 total

kitty -1 false 0.22s user 0.05s system 93% cpu 78Mb mem 0.290 total

(and yes, there's a kitty instance running already..)

Reply on news.ycombinator.com