6 ms·
"miss the point" feels a bit strong. Rather, I get the impression Alacritty's values don't match your own values in a terminal emulator, and that's totally OK.
by jwilm 8y ago
"miss the point" feels a bit strong. Rather, I get the impression Alacritty's values don't match your own values in a terminal emulator, and that's totally OK. Historically, input latency hasn't been considered a big pain point by most users.
That said, we do have a plan[1] to address this issue and be both high throughput _and_ low-latency.
[1]: https://github.com/jwilm/alacritty/issues/673 https://github.com/jwilm/alacritty/issues/673
- mindB 8y agoFair enough. :) I guess my stronger wording is because I don't understand workflows where being able to dump vast quantities of text to the terminal quickly is important. In general, a terminal emulator is for use by a human, and humans can't really process info at the throughput rate of other terminal emulators, much less the faster alacritty. All that said, I'm glad to hear there's a plan on the latency front.
- singingboyo 8y agoIt's not ideal, but one flow I end up using at some points is tmux-as-grep. Basically, something either gets dumped to terminal, and I use tmux's search. So then, for a combo of reasons (some good, some bad) I cat files to terminal on occasion, and I use tmux's search to find something in it. 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.
- jimpudar 8y agoI've never understood this mentality. If you can dump something to the terminal and use tmux search, you could just as easily use `less` which is pretty much purpose built for this.