Earlier quoted context omitted.
> Personally, the lack of scrollback and tabs is a dealbreaker for me Completely understandable. This decision was expected to be polarizing. > Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux. Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.
> Completely understandable. This decision was expected to be polarizing. The project being OK with polarizing decisions (instead of listening to the community and discussing it) is the dealbreaker for me. It's OK to build opinionated software, but not at such basic level.
Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
271–280 of 491 posts
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#272Earlier quoted context omitted.
> Solutions like tmux arguably exist because terminals have poor UIs Whilst I totally agree with you, I think Tmux is a lot like vim in its power. Along the same note, I'd wager a gTmux, much like gVim would be q real nice way to multiplex terminals when we get the UI to beat the TUI.
I mean Terminator is basically gTmux, right? They aren't quite the same: tmux is a terminal multiplexer, Terminator is a terminal emulator with tabs and panes. Both approaches have benefits and drawbacks. If you want keyboard only, I don't think GUIs can beat TUIs. But yeah, there's a learning curve. The problem with GUIs is a very display-session centric view. tmux/vim work fine over SSH, Terminator/gVim don't. With…
For the thing to replace the TUI, I'd expect something in between current terminals and X11. With the simple, limited (and thus easily remotable) data of the current terminal emulators, but with much more drawing capabilites than the current grid-limited ascii art.
I came to this idea when trying to get vim up to a full IDE. Trying to get even half of netbeans' interface into vim just takes so much space in the ascii grid. And anything dynamic moves half the screen a shitton.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#273Earlier quoted context omitted.
> Clippy can already work on stable No. But we plan to make it work.
Sorry Manish, I had meant that you can have code that can be built using a stable compiler while still using Clippy via another means. I typically use stable, but I run clippy on my code anyway. I realize that my post is confusing, I'll edit.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#274On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about rendering faster.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#275It sounds like a fun project, but I don't really understand what performance issues this solves? I don't think I've ever had an issue with slow terminal rendering using the default terminals on Ubuntu or Mac OS. What sort of applications do you run where it becomes an issue? On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about rendering fast…
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#276Earlier quoted context omitted.
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.
same. my tmux conf is really small (maybe 20 lines) and it does everything i want -- mouse support, vim keybinds, huge scrollback.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#277Earlier quoted context omitted.
> Personally, the lack of scrollback and tabs is a dealbreaker for me Completely understandable. This decision was expected to be polarizing. > Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux. Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.
> Completely understandable. This decision was expected to be polarizing. The project being OK with polarizing decisions (instead of listening to the community and discussing it) is the dealbreaker for me. It's OK to build opinionated software, but not at such basic level.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#278How much unsafe code was needed to make this work?
As Steve mentioned, it was mostly for ffi. There's also a few places where I'm doing my own bounds checking in order to provide nicer error messages. After doing the bounds checking, doing an index operation without the standard library's bounds checking requires unsafe.
Maybe I'll look into it and send a PR :)
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#279Earlier quoted context omitted.
Question: With a modern discrete GPU card wouldn't the texture atlas just end up in it's VRAM as cards these days commonly have >1GB of VRAM? (Sorry if this is a stupid question, still trying to grok opengl)
You really have nothing better to render on your GPU and store in that video memory than your terminal? I also use a web browser, and feel like it could use a performance boost a lot more than my terminal (particularly as I don't actually believe that using textures in this way is actually the most efficient way to render fonts with OpenGL).
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#280Less repeating that it is fast and more benchmarks instead!
Seriously. ^^^ How fast is it? I haven't had a terminal that was as fast as xterm with a matrox millenium ii. That was 20 years ago which is pretty sad. Of course the terminals look better these days.
I don't know why it's slower when you make the window smaller, or when it's not being displayed. I expect the answer is "some kind of OpenGL bullshit" but beyond that...
gnome-terminal takes about 5 minutes to do this, but it has unlimited scrollback and as far as I can see alacritty has no scrollback whatsoever.