Why does one need 500fps on terminal ? I don't understand the need for the GPU.
Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
251–260 of 491 posts
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#252Earlier quoted context omitted.
Hm. So, for that to work, I'd basically have to forever hardcode the terminal to launch tmux every single time. Basically, this new terminal + tmux = the old terminal behavior. I'm not saying this is necessarily a bad thing (haven't tried it), I'm just saying this is the way to get my scrollback... uh... back. Might as well ship the terminal with tmux as a hard dependency and launch a tmux child process by default.
In a tmux workflow, you're generally not spawning that many new terminal windows, instead you ^a+c to spawn a new tty within tmux.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#253I'm the author of Alacritty, and I'm here to answer any questions!
I just wanted to say that this looks like a fantastic and very cool project! Congratulations on the speed. Personally, the lack of scrollback and tabs is a dealbreaker for me. I know that I'm supposed to use tmux for that, but I can never remember how tmux scrollback and tab switching work without thinking about them. Plus I rely heavily on mouse selection of multi-screen text in the scrollback buffer. So I'm unlikel…
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#254Earlier quoted context omitted.
Looking at the code, it looks like this basically only relies on two things: inclusive ranges, and clippy. But you don't have to use clippy this way; it's just one way of doing it. So it's really one feature. EDIT: Oh oops, and custom derive, which is stable in a month. > I really hope they're able to stabilize it In general, "nightly" is never going to be stabilized. Remember, it's how Rust development works. Some p…
Just for completeness, there is one other major unstable feature that Alacritty requires . #![feature(step_trait)]. I forget the precise details, but I believe this was required for using newtype wrappers as a `Range` for indexing. Specifically, the grid can be indexed as a range like grid[Line..Line]
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#255I'm the author of Alacritty, and I'm here to answer any questions!
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#256Earlier quoted context omitted.
Very cool project, I'm trying it out, but this is an unrelated question: what is that Vim colorscheme in your screenshot? Do you have a link?
According to his dotfile repo[0] it is Tomorrow-Night-Bright. [0]: https://github.com/jwilm/dotfiles/blob/master/vimrc#L6
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#257Earlier quoted context omitted.
I switched to tmux a few years ago and never looked back. What is your problem with mouse? I have quite basic tmux config, very basic terminal emulator (st) and enjoy mouse scrolling even in nested tmux scenarios. Selection is done with vim keybindings which is much faster than mouse especially if you scroll and look for something visually. I can relate to your feelings. In the beginning I was _very_ skeptical about…
I agree. I also have a very basic tmux/vim setup and I can scroll, copy/paste and even resize tmux panels with the mouse.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#258Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#259Hm, if we're doing GPU rendering for speed, I'd suggest uploading vector glyph data to the GPU and rasterising on the GPU in the pixel shader, rather than using FreeType. See here: http://wdobbie.com/post/gpu-text-rendering-with-vector-textu... . The WebGL Demo is really impressive - it lets you zoom in and out on a multi-page PDF at speeds I haven't seen anywhere else.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#260Earlier quoted context omitted.
> Features like ... are better provided by a terminal multiplexer I would strongly argue that this thinking is putting the cart before the horse. I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to fo…
Thank you for the thoughtful comment. There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider. I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to…