That said, we do have a plan[1] to address this issue and be both high throughput _and_ low-latency.
All that said, I'm glad to hear there's a plan on the latency front.
I don't consider it contrary to the project's goals if it's something that can be done unobtrusively. Given your description, it sounds like this may be something we could support easily. I filed #1544 to track this. Thanks for the suggestion!
If you want notifications on any developments here, please subscribe to this GitHub issue: https://github.com/jwilm/alacritty/issues/673
Ultimately, it would be great if we could benchmark against every terminal emulator, but that can become a very time-consuming task. If there's another emulator you feel should be included, we can consider it for future updates/benchmarks.
[0] https://news.ycombinator.com/item?id=17635869 [1] https://hyper.is/
Depends on your priorities and what you are willing to sacrifice for it. High bandwidth terminal emulators will cost CPU and battery life. I'd opt for longer battery life.
The choice is nice to have though.
The idea isn't that the I'm processing at the throughput rate of the emulator - it's more that a low throughput rate delays when I can start actually looking for something useful.
Also vim performance is really great inside VMs in Alacritty on my 6th gen core i5 laptop :)
Edit: oh, just saw your other comment
We haven't intentionally opted out of this that I know of, we just didn't start Alacritty from an XCode project on macOS.