undefined | Better HN

0 pointsjwilm9y ago0 comments

Terminal performance is fine at smaller sizes and with less going on.

In a multi-pane tmux window with vim, performance issues start to become noticeable. Many people I've talked to have experienced a situation where a bunch of output is being written to the screen, they panic to hit C-c, and then all you can do is wait for it to finish. This just isn't an issue with Alacritty.

Alacritty is about having tools that don't get in your way and don't distract you from what you're trying to accomplish.

0 comments

3 comments · 2 top-level

ericbb9y ago· 1 in thread

With the C-c issue specifically, I don't think that emulator throughput is the most likely culprit.

It could be that the emulator is not handling inputs fairly: maybe it tries to process all available input from the pseudoterminal before processing the next batch of keyboard input. Or it could be that the pseudoterminal (kernel driver) is not configured to send the signal as expected. Or it could be that the process you're trying to interrupt is not responsive to the signal.

I maintain a terminal emulator that is not optimized at all and I just tested interrupting a process that was dumping one gigabyte of text to the screen. The interrupt was handled instantaneously.

JdeBP9y ago

It isn't the most likely culprit. The mosh people point out that the place where people hit this is with a SSH session to another machine. Where the data are actually building up is the SSH connection. It's not a problem with the terminal emulators at all.

1_2__39y ago

That's a lot more to do with Vim that your terminal emulator. It chokes on some files pretty reliably.

j / k navigate · click thread line to collapse