Live data from Hacker News

Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

blog.jwilm.io

271–280 of 491 posts

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#271
post #60

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.

Of course it's always okay to build opinionated software at any level. If you don't like, don't use it.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#272
post #193

Earlier 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…

The multiplexer v emulator is the key difference. At least for me. Exactly because of the ssh and session persistence you mean.

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

#273

Earlier 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.

Ah, thanks!

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#274
It 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 faster.

[1] https://mosh.org/

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#275

It 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…

Maybe it's more in reaction to the recent wave of editors and terminals using JavaScript as their primary language ?

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#276

Earlier 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.

Are y'all on Linux/xterm or something? I've had trouble getting this to work in OSX with the default terminal. At one point I got it to partially work by installing some scary looking plugins, but it broke other mouse behavior for me (copy/paste I think).

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#277
post #60

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.

Doesn't being opinionated necessarily preclude listening to a community and following consensus?

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#278
post #217

How 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.

Couldn't you use get instead of [] for this?

Maybe I'll look into it and send a PR :)

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#279
post #190

Earlier 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).

What's your currently preferred way to render text with OpenGL?

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#280
post #40

Less 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.

On my laptop this terminal is not very fast. A cached 'find /' runs in 11 seconds on an xterm, 17 seconds on maximized alacrity when it's on screen, 25 seconds on alacritty if it's off-screen, and 44 seconds on a 80x24 alacritty.

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.

Post reply on HN