I really, really like this so far. Interestingly, it's dependence on tmux (which I really like overall) for 'extra' terminal features presents some problems for performance and usability.<p>Tmux has its own non-trivial rendering bottlenecks, the most significant of which comes into play when you have multiple clients attached to a session. As a test, I went into a notes folder and did `grep -r e .`. When Alacritty was sized larger than mate's default terminal, mate's default terminal finished rendering first. When Alacritty was sized smaller than mate's terminal, Alacritty finished first. Also of note was that Alacritty running tmux rendered slower than mate's default terminal without tmux. This was an uncontrolled experiment, especially since this was a tmux session with a couple windows with a couple panes per window, on a tmux server with 2 other sessions (with a lot of vim windows etc), but something tells me the results would be the same if I used a tmux server with one session/window/pane. As a tmux user, this isn't a huge deal to me, but it should be concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable.<p>My biggest concern, however, is not performance related, but usability related. Consider this use case: Alacritty -> ssh into remote server -> run tmux on remote server. How am I supposed to paste anything into that remote tmux session now? Am I supposed to nest my remote tmux session in a local tmux session? That sounds awful! I've found satisfactory workarounds to the lack of copy/paste when working locally, but it falls apart when I can't rely on duplicating the tmux register to the clipboard (and vice versa) because the clipboard is remote.<p>If I can find a workaround to the remote paste issue, I will probably use Alacritty exclusively. Otherwise, I can't use this terminal for remote work, and I'd rather not run two different terminals just so that rendering is faster _sometimes_